SIP SDP Issues

[tobyboulton]

Hi There,

I'm trying to modify my SDP headers from an internal IP to an external IP.

I have written a SIP profile but it isn't doing anything at all.

Would somebody be able to have a glance at my config for me? (see attached)

I have also been told that my CME is sending malformed SDP packets.

It is sending 

Cisco-SIPGateway/IOS-12.x v=0 o=CiscoSystemsSIP-GW-UserAgent 4398 2360 IN IP4
10.0.1.254 s=SIP Call c=IN IP4 10.0.1.254 t=0 0 m=audio 17474 RTP/AVP 8 101 c=IN IP4 203.x.x.152 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16 a=ptime:20

I have been told it is meant to look like 

v=0 o=TRUNKPROVIDOR 929606340 929606340 IN IP4 125.254.48.7 s=TRUNKPROVIDOR-AST c=IN IP4 125.x.x.7 t=0 0 m=audio 14566 RTP/AVP 8 18 3 101 a=rtpmap:8
PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv 

Would somebody be able to point me in the right direction?

Thanking you in advance. 

[Ayodeji Okanlawon · Accepted solution]

Hi Toby,

Looks like your provider is not complying with RFC. Here is the analysis of both traces.

++ Your Trace has multiple connection info one at session level and one at media level +++

Cisco-SIPGateway/IOS-12.x
v=0
o=CiscoSystemsSIP-GW-UserAgent 4398 2360 IN IP4 10.0.1.254
s=SIP Call
c=IN IP4 10.0.1.254 --------------<<< Session description >>>
t=0 0
m=audio 17474 RTP/AVP 8 101
c=IN IP4 203.x.x.152--------------<< Media description >>
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16 a=ptime:20
--------------------------------------------------------

++ Their trace has a single connection info at the session level ++
v=0
o=TRUNKPROVIDOR 929606340 929606340 IN IP4 125.254.48.7
s=TRUNKPROVIDOR-AST
c=IN IP4 125.x.x.7
t=0 0
m=audio 14566 RTP/AVP 8 18 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

++ To argure your corner and get them to re-write their SIP stack here is what the RFC says ++

+++ RFC 4566 +++

5.7. Connection Data ("c=")

c=<nettype> <addrtype> <connection-address>

The "c=" field contains connection data.

A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values
override the session-level settings for the respective media.

The "session description" above is the bit before any m= lines.
The "media descriptions" start with an m= line.
So an SDP has 1 session description section and can have
multiple media descriptions.

so as examples or positioning of c= lines, you can have:

1. There is one c= line at the session description
Each media description uses the connection information from
that top c= line.
c=.... // session description
m=.... // 1st media description
a=.....
m=.... // 2nd media description
a=.....

or


2. Each media description has its own c= line
(There is no session description c= line):


// session description (no c= line)
m=.... // 1st media description
c=....
a=.....
m=.... // 2nd media description
c=....
a=.....


or

3. There is a session description c= line but the first
media description has its own c= line , so the first
media description's c= line overrides the session description c= line.
The 2nd media description uses the c= line in the session description.
c=.... // session description
m=.... // 1st media description
c=....
a=.....
m=.... // 2nd media description
a=.....

Your SIP request is correctly formatted and if they are referring to the absence of media direction in your SDP

ie a=sendrecv

Here is what the RFC says on that as well

++ RFC4566 ++
a=sendrecv
...
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the conference type
"broadcast" or "H332" (see below).

Finally on your sip profile question, I can see this working as you have configured it. In your SDP you can see the connection-info in your media description different and to what you have at the session description, this suggests to me that it is working as configured

[Rajan]

Great analysis (+5)