Hi!
Same issue with 1.4.0. I'm migrating from 1.1.1 to 1.4.0, but force_rtp_proxy() now adds a sdp line with a beginning 0x00, so line looks like 0000 00 61 3d 6e 6f 72 74 70 70 72 6f 78 79 3a 79 65 .a=nortpproxy:ye 0010 73 s But no \r\n\r\n in front anymore in 1.4.0.
Someone to direct me to the propper source file,pls?
Walter
-----Ursprüngliche Nachricht----- Von: users-bounces@lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] Im Auftrag von Daniel-Constantin Mierla Gesendet: Montag, 15. September 2008 14:23 An: Jerome Martin Cc: users@lists.kamailio.org Betreff: Re: [Kamailio-Users] SDP ending with CRLF and a=nortpproxy:yes
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@lists.kamailio.org mailto:Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@lists.kamailio.org mailto:Users@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-- Daniel-Constantin Mierla http://www.asipto.com
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users