Hello everyone,
I've already noticed a few posts on that topic, but none has been answered up to resolution of the problem.
Here is the issue : I am receiving SDP in INVITEs from a Cisco AS5350 (IOS 12.4) gateway that contain two identical c= lines for the same media.
When using force_rtp_proxy, only the last one is replaced by my proxy IP. If I use the mangler module on top of it, then both are replaced, but the one already replaced by force_rtp_proxy is now a concatenation of twice the proxy IP address.
Is there a way to deal with this so that both lines are replaced ? Depending on which equipement gets the REQUEST next, either the first or the second line is used, and this leads to RTP proxy problems.
Best Regards,
Jerome Martin
Hello Jerome,
Check the following link: http://www.openser.org/docs/modules/1.1.x/nathelper.html#AEN275
c - flags to change the session-level SDP connection (c=) IP if media-description also includes connection information.
Hope this helps, Ovidiu Sas
On 11/27/06, Jerome Martin jmartin@longphone.fr wrote:
Hello everyone,
I've already noticed a few posts on that topic, but none has been answered up to resolution of the problem.
Here is the issue : I am receiving SDP in INVITEs from a Cisco AS5350 (IOS 12.4) gateway that contain two identical c= lines for the same media.
When using force_rtp_proxy, only the last one is replaced by my proxy IP. If I use the mangler module on top of it, then both are replaced, but the one already replaced by force_rtp_proxy is now a concatenation of twice the proxy IP address.
Is there a way to deal with this so that both lines are replaced ? Depending on which equipement gets the REQUEST next, either the first or the second line is used, and this leads to RTP proxy problems.
Best Regards,
Jerome Martin
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hello Ovidiu and Bogdan,
Thanks a lot for both of your answers. I should have be more carefull with that issue, as I'm afraid I should have solved this myself, especially because it has already been specifically addressed both here and in the v1.1 nathelper module.
The thing is I did read about the "c" option in force_rtp_proxy documentation, I just got confused by session/media description in SDP. Now that I've just read the RFC2327 (which I already went through, but not carefully enough), everything is clear as crystal :-)
So, if I have a message for people like me reading this : RTFR(FCs) !!! (this is sooo much compatible with the Fu****g word than the plain old RTFM.).
Bogdan wrote:
this is a topic that was debated couple of times. according to the SDP RFC, the connection information (c=) can exists both in session description (s= section ) and in media description (m= section). This because a session may contain several media description and if the c= in media is not specify, the one from session is used.
Now that I've read it, I'm gonna be bitchy about it : ain't the session description delimited by "v=" and not "s=", according to RFC2327 ? ;-p
Thanks again, I was really amazed by such a fast answer (first time I post here).
Best Regards, Jerome Martin
Hi Jerome,
Jerome Martin wrote:
Hello Ovidiu and Bogdan,
Thanks a lot for both of your answers. I should have be more carefull with that issue, as I'm afraid I should have solved this myself, especially because it has already been specifically addressed both here and in the v1.1 nathelper module.
The thing is I did read about the "c" option in force_rtp_proxy documentation, I just got confused by session/media description in SDP. Now that I've just read the RFC2327 (which I already went through, but not carefully enough), everything is clear as crystal :-)
So, if I have a message for people like me reading this : RTFR(FCs) !!! (this is sooo much compatible with the Fu****g word than the plain old RTFM.).
Bogdan wrote:
this is a topic that was debated couple of times. according to the SDP RFC, the connection information (c=) can exists both in session description (s= section ) and in media description (m= section). This because a session may contain several media description and if the c= in media is not specify, the one from session is used.
Now that I've read it, I'm gonna be bitchy about it : ain't the session description delimited by "v=" and not "s=", according to RFC2327 ? ;-p
yes, that is correct - it is v= and not s= - mea culpa :)
regards, bogdan
Thanks again, I was really amazed by such a fast answer (first time I post here).
Best Regards, Jerome Martin
Hi Jerome,
this is a topic that was debated couple of times. according to the SDP RFC, the connection information (c=) can exists both in session description (s= section ) and in media description (m= section). This because a session may contain several media description and if the c= in media is not specify, the one from session is used.
It looks lie the Cisco GW sets both c= (in session and media description) - it is redundant, but correct (c= in media has priority over the one in media description). Nathelper changes only the one to be used - If present, the one from media, otherwise the one from session section.
If from some reasons, the other party is buggy and looks for c= in session (even if C= is present in media part), you should try to use the "c" flag for force_rtp_proxy(): http://www.openser.org/docs/modules/1.2.x/nathelper.html#AEN275
regards, bogdan
Jerome Martin wrote:
Hello everyone,
I've already noticed a few posts on that topic, but none has been answered up to resolution of the problem.
Here is the issue : I am receiving SDP in INVITEs from a Cisco AS5350 (IOS 12.4) gateway that contain two identical c= lines for the same media.
When using force_rtp_proxy, only the last one is replaced by my proxy IP. If I use the mangler module on top of it, then both are replaced, but the one already replaced by force_rtp_proxy is now a concatenation of twice the proxy IP address.
Is there a way to deal with this so that both lines are replaced ? Depending on which equipement gets the REQUEST next, either the first or the second line is used, and this leads to RTP proxy problems.
Best Regards,
Jerome Martin
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users