[Kamailio-Users] SDP ending with CRLF and a=nortpproxy:yes

Daniel-Constantin Mierla miconda at gmail.com
Mon Sep 15 14:22:52 CEST 2008


Hi Jerome,

On 09/15/08 13:43, Jerome Martin wrote:
> Hi All,
>
> Just FYI, I had to disable the nortpproxy test here because it breaks 
> thomson ST2030 endpoints : with that line, they would just plain 
> ignore the messages containing the SDP ...
was i with malformed SDP (empty lines inside SDP before the a= line), or 
just the presence of the a=nortpproxy:yes line made the ST2030 go mad?

Cheers,
Daniel

>
> Cheers,
>
> On Fri, 2008-09-12 at 18:12 +0300, Daniel-Constantin Mierla wrote:
>> On 09/11/08 16:10, Klaus Darilion wrote:
>> > A similar bug was also described in opensips. They tried to fix it but 
>> > the bug is still present. I wonder if this is something new or if the 
>> > bug is thre since the beginning of nathelper but did not occured until now
>> >   
>> maybe this can be fixed by using the sdp parser available now in core. 
>> nathelper has quite limited sdp parsing capabilities now. the issue is 
>> to find the proper hook to add the lump with
>>
>> a=nortpproxy:yes\r\n"
>>
>> Cheers,
>> Daniel
>>
>>
>> > klaus
>> >
>> > Aymeric Moizard schrieb:
>> >   
>> >> Hi,
>> >>
>> >> I just happen to find an issue with a software
>> >> trying to call through my openser-1.3.1
>> >>
>> >> After inserting "a=nortpproxy:yes\r\n", the
>> >> message coming out openser is:
>> >>
>> >> [normal sdp packet]
>> >> a=fmtp:101 0-15\r\n
>> >> \r\n
>> >> \r\n
>> >> "a=nortpproxy:yes\r\n"
>> >>
>> >> No matter who is responsible in that specific case (the SDP received 
>> >> by openser with several \r\n looks not compliant to me).
>> >>
>> >> I think openser should add "a=nortpproxy:yes" in different place
>> >> in the SDP packet: NOT at the end of the SDP body. The "a=nortpproxy:yes"
>> >> should be either put at the global attribute level or right below a m= 
>> >> line.
>> >>
>> >> This approach would solve such issue and would be much more
>> >> adequate to the requirement: currently it's not very possible
>> >> to relay an audio stream and not relay a video stream with the
>> >> current approach.
>> >>
>> >> tks,
>> >> Aymeric MOIZARD / ANTISIP
>> >> amsip - http://www.antisip.com
>> >> osip2 - http://www.osip.org
>> >> eXosip2 - http://savannah.nongnu.org/projects/exosip/
>> >>
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>
>> >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> >>     
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.kamailio.org <mailto:Users at lists.kamailio.org>
>> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>> >
>> >   
>>
>>     
>
> *Jérôme Martin **| **LongPhone*
> *Responsable Architecture Réseau*
> 122, rue la Boetie | 75008 Paris
> Tel :  +33 (0)1 56 26 28 44
> Fax : +33 (0)1 56 26 28 45
> Mail : *jmartin*@longphone.fr
> Web : www.longphone.com <http://www.longphone.com>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com





More information about the Users mailing list