[Freeswitch-users] rtpmap line missing on answer

[Sean Eichhorn]

Yeah, they're negotiating the same codec on both sides.
The problem is the way Cisco handles the negotiation.  Here's an example of what I see in Freeswitch:

Received from CALLED :

  SIP/2.0 200 OK
   Via: SIP/2.0/UDP A.B.C.D;rport;branch=z9hG4bKXZZ18p8tD03cS
   From: "pending" <sip:xxxxxxxx02 at A.B.C.D>;tag=NH1HrNe744HSB
   To: <sip:sean at E.F.G.H:5060>;tag=622555CC-408
   Date: Mon, 23 May 2011 23:50:56 GMT
   Call-ID: 69258f8c-0038-122f-19ba-000c29c18d38
   CSeq: 12760849 INVITE
   Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
   Allow-Events: telephone-event
   Contact: <sip:xxxxxxxx75 at E.F.G.H:5060>
   Supported: replaces
   Supported: sdp-anat
   Server: Cisco-SIPGateway/IOS-12.x
   Content-Type: application/sdp
   Content-Disposition: session;handling=required
   Content-Length: 311

   v=0
   o=CiscoSystemsSIP-GW-UserAgent 4080 7999 IN IP4 E.F.G.H
   s=SIP Call
   c=IN IP4 E.F.G.H
   t=0 0
   m=audio 17122 RTP/AVP 0 19 101 100
   c=IN IP4 E.F.G.H
   a=rtpmap:0 PCMU/8000
   a=rtpmap:19 CN/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=rtpmap:100 X-NSE/8000
   a=fmtp:100 192-194

Sent to CALLING :
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP I.J.K.L:5060;branch=z9hG4bK4C2B6C64
   From: <sip:xxxxxxxx02@ I.J.K.L >;tag=9020153C-21B3
   To: <sip:xxxxxxxx75 at A.B.C.D>;tag=m87rptX37UU6F
   Call-ID: AFADEF2E-84CC11E0-B1D4F23A-27804614@ I.J.K.L
   CSeq: 101 INVITE
   Contact: <sip:xxxxxxxx75@ A.B.C.D:5060;transport=udp>
   User-Agent: GCI
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
   Min-SE: 1800
   Content-Type: application/sdp
   Content-Disposition: session
   Content-Length: 261
   Remote-Party-ID: "Outbound Call" <sip:sean@ A.B.C.D >;party=calling;privacy=off;screen=no

   v=0
   o=FreeSWITCH 1995227603 1995227604 IN IP4 A.B.C.D
   s=FreeSWITCH
   c=IN IP4 A.B.C.D
   t=0 0
   m=audio 24636 RTP/AVP 0 19 101
   c=IN IP4 A.B.C.D
   a=rtpmap:0 PCMU/8000
   a=rtpmap:19 CN/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16

This is not the case when the call direction is reversed.  Like I said, the only difference appears to be that one direction is responding with a 183 while this one is responding with a 200.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110523/dc77f41e/attachment-0001.html