cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1090
Views
0
Helpful
2
Replies

Weird RTP port usage with SIP early media

Yorick Petey
Level 4
Level 4

I have a SIP/PSTN gateway between an ISDN BRI and a CallManager 5.1. I can make and receive calls with it.

But there's something weird when I look at the debug traces (debug ccsip). The gateway uses the 183 SIP response with SDP for Early Media.

I can see that the caller waits media on the 25148 UDP port (SDP of INVITE) and the caller on the 18248 UDP port (SDP of Session Progress).

But, the callee tries to send RTP stream (maybe the ringback tone) to the 25149 port instead of 25148. WHY?

Maybe it's normalized in a SIP RFC that the early media must be sent to the port+1? I couldn't find this ... Does anybody know why?

CCM --> SIPGW

*Jun 15 10:43:53.595: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:12345@10.168.3.4:5060 SIP/2.0

Via: SIP/2.0/TCP 10.168.36.16;branch=z9hG4bK12dcdb19d9

Remote-Party-ID: <sip:8001@10.168.36.16>;party=calling;screen=yes;privacy=off

From: <sip:8001@10.168.36.16>;tag=edd7f565-1202-4cee-a374-66f239d2607f-29299013

To: <sip:12345@10.168.3.4>

Date: Fri, 15 Jun 2007 10:43:38 GMT

Call-ID: 4502ae80-67216d5a-98-1024a80a@10.168.36.16

Supported: timer,replaces

Min-SE: 1800

User-Agent: Cisco-CCM5.1

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

CSeq: 101 INVITE

Contact: <sip:8001@10.168.36.16:5060;transport=tcp>

Expires: 180

Allow-Events: presence

Session-Expires: 1800

Max-Forwards: 70

Content-Type: application/sdp

Content-Length: 212

v=0

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.168.36.16

s=SIP Call

c=IN IP4 10.168.36.16

t=0 0

m=audio 25148 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

SIPGW --> CCM

*Jun 15 10:43:53.615: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.168.36.16;branch=z9hG4bK12dcdb19d9

From: <sip:8001@10.168.36.16>;tag=edd7f565-1202-4cee-a374-66f239d2607f-29299013

To: <sip:12345@10.168.3.4>;tag=3459EA6C-950

Date: Fri, 15 Jun 2007 10:43:53 GMT

Call-ID: 4502ae80-67216d5a-98-1024a80a@10.168.36.16

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 101 INVITE

Allow-Events: telephone-event

Content-Length: 0

SIPGW --> CCM

*Jun 15 10:43:56.031: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 183 Session Progress

Via: SIP/2.0/TCP 10.168.36.16;branch=z9hG4bK12dcdb19d9

From: <sip:8001@10.168.36.16>;tag=edd7f565-1202-4cee-a374-66f239d2607f-29299013

To: <sip:12345@10.168.3.4>;tag=3459EA6C-950

Date: Fri, 15 Jun 2007 10:43:53 GMT

Call-ID: 4502ae80-67216d5a-98-1024a80a@10.168.36.16

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

Allow-Events: telephone-event

Contact: <sip:12345@10.168.3.4:5060;transport=tcp>

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 241

v=0

o=CiscoSystemsSIP-GW-UserAgent 7717 1384 IN IP4 10.168.3.4

s=SIP Call

c=IN IP4 10.168.3.4

t=0 0

m=audio 18248 RTP/AVP 8 101

c=IN IP4 10.168.3.4

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

SIPGW --> CCM

*Jun 15 10:43:59.691: UDP: sent src=10.168.3.4(18249), dst=10.168.36.16(25149), length=96

*Jun 15 10:44:01.303: UDP: sent src=10.168.3.4(18249), dst=10.168.36.16(25149), length=96

*Jun 15 10:44:04.735: UDP: sent src=10.168.3.4(18249), dst=10.168.36.16(25149), length=96

*Jun 15 10:44:10.995: UDP: sent src=10.168.3.4(18249), dst=10.168.36.16(25149), length=96

*Jun 15 10:44:13.559: UDP: sent src=10.168.3.4(18249), dst=10.168.36.16(25149), length=96

2 Replies 2

carenas123
Level 5
Level 5

While the PSTN provides inband progress information to signal early media (such as a ring tone or a busy signal), the same does not hold true for SIP. The originating party includes Session Description Protocol (SDP) information, such as codec usage, IP address, and port number, in the outgoing INVITE message. In response, the terminating party sends its codec, IP address, and port number in a 183 Session Progress message to indicate possible early media.

The 183 Session Progress response indicates that the message body contains information about the media session. Both 180 Alerting and 183 Session Progress messages may contain SDP, which allows an early media session to be established prior to the call being answered.

When early media needs to be delivered to SIP endpoints prior to connection, Cisco CallManager always sends a 183 Session Progress message with SDP. While Cisco CallManager does not generate a 180 Alerting message with SDP, it does support the 180 Alerting message with SDP when it receives one.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00801ec5cd.html

Thank you for but your response doesn't help me.

My question was : why the early media ports used by the IPIPGW (the callee) are #port+1 mentionned in the SDP 183 message ?

In the traces, we can see that the CCM waits RTP stream on port 25148 but the IPIPGW sends it ont he udp port 25149.

I would like to know if this behaviour is normal (in the RFC?).

Thank you.

Yorick

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: