Hi, I am not sure sending INVITE without SDP indicates call hold. Can you please refer to which section in 3261 refer the same? Invite without SDP can be considered as Request offer, and some time in these cases far end responds with Complete codec list. For call hold we need to either send INVITE with SDP having "a=inactive" attributes or connection IP for media line to be 0.0.0.0.
Also regarding the behavior, I think if PBX does not support the G729 variant then it should have not offered it. If PBX has not offered it in initial invite then Far end might not select the same. Can you share the INVITE SDP? Regards Sunil Verma -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Johnson, Michael A Sent: Tuesday, June 28, 2011 12:30 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Re-Invite codec renegotiation. I have an issue with a vendor where a call placed from a phone that negotiates G.729 (ISP supports both G.729 & G.711) 200 OK with SDP: t=0 0 m=audio 9000 RTP/AVP 8 0 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 When I place the call on-hold, I send an invite without SDP, this appears OK according to RFC 3261. My issue is that when placing the call on-hold the PBX (server) has no compression resources and so cannot support G.729. This should, I believe negotiate G.711 but is not. The 200 OK I get back from the ISP offers both options: t=0 0 m=audio 16460 RTP/AVP 18 101 a=rtpmap:18 G729a/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv The PBX actually waits for an internal timer to expire before finally accepting the offered G.729 codec. ACK sip:0386023724@192.168.175.132:5060;url-cookie=SBCCW-fr7ft3pl6t5d9;trans port=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.8.80:5060;branch=z9hG4bK174147504-93234099 Max-Forwards: 70 From: "D.80" <sip:396241...@as.staging.ipvs.net>;tag=0_158177504-93234094 To: <sip:0386023...@as.staging.ipvs.net>;tag=1839278173-1304385963032 Call-ID: 158177504-93234092@192.168.8.80 CSeq: 4 ACK Contact: "D.80" <sip:396241080@192.168.8.80:5060;transport=udp> Content-Type: application/sdp Content-Length: 200 v=0 o=- 2475 2476 IN IP4 192.168.8.80 s=- c=IN IP4 192.168.8.80 t=0 0 m=audio 9000 RTP/AVP 18 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 I have raised this as a fault, however the vendor has stated that this complies with RFC3261, and to be honest, I cannot find anything specific to contradict them. The best I can see is below, but this only states should. Is this acceptable operation, according to the RFC's, or is there an RFC I'm overlooking? A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13<http://tools.ietf.org/html/rfc3261#ref-13>] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session. Michael Johnson _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
