Hello Anthony. Maybe I want not so clear, let me explain. I do not want to apply any codec manipulation, I'm working on a prototype endpoint module that has "proxy media capabilty" and wants to interoperate with other endpoints. What I saw is that in a sofia vs sofia call (proxy mode+late negotiation) they exchange through FS calling/called endpoint capability looking at SDP session carried by channel variables, so internally they use SDP O/A scheme. I thought that "ep_codec_string"->SWITCH_ORIGINATOR_CODEC_VARIABLE could be used to exchange capability without using a protocol specific format (SDP). If this is not the case, what's the right way to negotiate capability between endpoints in proxy mode? Than you. Giovanni PS: I did not find any existing endpoint except sofia that support this. Am I right? -----Original Message----- From: freeswitch-dev-bounces@lists.freeswitch.org on behalf of Anthony Minessale Sent: Fri 10/21/2011 5:06 PM To: freeswitch-dev@lists.freeswitch.org Subject: Re: [Freeswitch-dev] Strange behaviour in SOFIA SIP any codec manipulation techniques and proxy media mode are not compatible. Proxy media mode means stay completely out of the codec negotiation process. On Thu, Oct 20, 2011 at 3:11 PM, Visciano Giovanni <Giovanni.Visciano@italtel.it> wrote:
Preconditions on sip profile ---------------------------- inbound-codec-prefs NOT set outbound-codec-prefs NOT set inbound-proxy-media=TRUE inbound-bypass-media=FALSE inbound-late-negotiation=TRUE + inherit_codec=TRUE
TEST scenario ------------- SIP phone send INVITE with SDP to FS
INVITE SDP[codelist=PCMA, PCMU, G722, G729] --> FS
FS has just the CORE_PC_MODULE [PCMA, PCMU, PASS-THR, VIDEO-PASS-THR, L16]
The "ep_codec_string" channel variable is loaded with [PCMA, PCMU]
EXPECTED -------- In "proxy-media + late-negotiation" scenario: ep_codec_string=[PCMA,PCMU,G722,G729]
PROBLEM ------- According to the documentation (http://wiki.freeswitch.org/wiki/Codec_negotiation):
"ep_codec_string: This variable is only available if late negotiation is enabled on the profile. It's a readable string containing all the codecs proposed by the calling endpoint." and "inherit_codec=true (only applicable when late-negotiation is enabled) will take the codec negotiated when the B leg answers and pass it to the A leg so it also uses the same codec (if the A leg supports it); otherwise, it will use whatever it can from its own list"
The variable ep_codec_string doesn't contain ALL the codecs proposed by the calling endpoint. It contains the intersection between the codecs proposed by the calling and the codecs loaded in FS. In proxy-media / no-media configuration the called endpoint doesn't have the calling codec list so he can't negotiate using all the capabilities available. (I'm working on a test endpoint module that should work in proxy and no-media configuration ... mod_sofia vs mod_sofia works because they look at the remote sdp variable)
Source reference - sofia_glue.c->sofia_glue_set_r_sdp_codec_string()
Regards, Giovanni
Internet Email Confidentiality Footer
********************************************************************************************************************************************
La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto.
This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred. ********************************************************************************************************************************************
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900 _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org