06-15-2007 04:53 AM - edited 03-14-2019 10:05 PM
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
06-21-2007 06:13 AM
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.
06-21-2007 06:22 AM
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
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: