Hi All.
I'm looking at a possible codec negotiation problem between two
endpoints - let's call them A and B.
What I'm seeing is that endpoint B does not seem to negotiate the SDP
codec list correctly when endpoint A attempts to go off-hold.
In the following trace (hopefully anonymised) I can't see how endpoint B
can expect to receive or send audio, since it appears to negotiate away
all but the telephone-event (101) codec.
I know that the IETF does not define the user-facing behaviour of the
endpoints, just the protocol interactions, but can anyone suggest what
endpoint A should do in this case? It has been suggested that it should
roll back to using the audio codec list previously negotiated, but is
that correct?
Endpoint A goes on-hold:
Request-Line: INVITE sip:[EMAIL PROTECTED]:port SIP/2.0
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 0 787833650 IN IP4
xxx.xxx.xxx.xxx
Session Name (s): SIP Call
Connection Information (c): IN IP4 0.0.0.0
Time Description, active time (t): 0 0
Media Description, name and address (m): audio pppp RTP/AVP
0 8 18 2 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:2 G726-32/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): ptime:20
Endpoint B responds:
Status-Line: SIP/2.0 200 OK
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 1 4 IN IP4 yyy.yyy.yyy.yyy
Session Name (s): -
Connection Information (c): IN IP4 0.0.0.0
Time Description, active time (t): 0 0
Media Description, name and address (m): audio qqqq RTP/AVP
0 8 18 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Endpoint A comes off-hold:
Request-Line: INVITE sip:[EMAIL PROTECTED]:ppp SIP/2.0
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 0 787833651 IN IP4
xxx.xxx.xxx.xxx
Session Name (s): SIP Call
Connection Information (c): IN IP4 xxx.xxx.xxx.xxx
Time Description, active time (t): 0 0
Media Description, name and address (m): audio pppp RTP/AVP
0 8 18 2 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:2 G726-32/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): ptime:20
Endpoint B responds:
Status-Line: SIP/2.0 200 OK
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 1 5 IN IP4 yyy.yyy.yyy.yyy
Session Name (s): -
Connection Information (c): IN IP4 zzz.zzz.zzz.zzz
Time Description, active time (t): 0 0
Media Description, name and address (m): audio rrrr RTP/AVP
101
Media Attribute (a): rtpmap:101 telephone-event/8000
Result: Endpoint A thinks that there are no audio-bearing codecs
available, and drops the call.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
