[Serdev] [Tracker] Resolved: (SER-369) force_rtp_proxy does rewrite session-level connection data if media-level connection data is present

Jan Janak (JIRA) tracker at iptel.org
Mon Jun 23 12:16:15 CEST 2008


     [ http://tracker.iptel.org/browse/SER-369?page=all ]

Jan Janak resolved SER-369.
---------------------------

    Resolution: Won't Fix

See the comments.

> force_rtp_proxy does rewrite session-level connection data if media-level connection data is present
> ----------------------------------------------------------------------------------------------------
>
>                 Key: SER-369
>                 URL: http://tracker.iptel.org/browse/SER-369
>             Project: SER
>          Issue Type: Improvement
>          Components: NAT Traversal
>    Affects Versions: 2.0
>            Reporter: Marcus Better
>            Priority: Minor
>
> Some SIP clients, e.g. SJPhone 1.65, create session descriptions with two c= lines, one session-level and one media-level:
> v=0
> o=- 3415474221 3415474221 IN IP4 192.168.2.102
> s=SJphone
> c=IN IP4 192.168.2.102
> t=0 0
> m=audio 49152 RTP/AVP 3 97 98 8 0 101
> c=IN IP4 192.168.2.102
> a=rtpmap:3 GSM/8000
> a=rtpmap:97 iLBC/8000
> a=rtpmap:98 iLBC/8000
> a=fmtp:98 mode=20
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=setup:active
> a=sendrecv
> This is rewritten by force_rtp_proxy into:
> v=0
> o=- 3415474221 3415474221 IN IP4 192.168.2.102
> s=SJphone
> c=IN IP4 192.168.2.102
> t=0 0
> m=audio 35262 RTP/AVP 3 97 98 8 0 101
> c=IN IP4 10.1.2.3
> a=rtpmap:3 GSM/8000
> a=rtpmap:97 iLBC/8000
> a=rtpmap:98 iLBC/8000
> a=fmtp:98 mode=20
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=setup:active
> a=sendrecv
> a=nortpproxy:yes
> As you see, only the media-level c entry was rewritten. This is technically OK since it takes precedence over the session-level connection data, but it seems to confuse broken SIP endpoints, and it looks a bit odd. For instance it seems the Asterisk echo server at 613 at fwd.pulver.com has problems with this (need to verify this).
> It would seem more logical to rewrite all c= lines in the same way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.iptel.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the Serdev mailing list