I apologise if I have been unclear in the posting. A point to mention is that this vendor (Mitel) do not support 'hold' in the correct sense. They use 'consultation-hold' or the first stage of a transfer as their hold mechanism. While I disagree with this approach, it is not the issue I am fighting with them.
Secondly, Sunil has stated ' if PBX does not support the G729 variant then it should have not offered it'. This is obviously an issue with my post, and I have not explained it well. The 'hold' is initiated by the Mitel PBX, but does not include an SDP in the re-invite. The ISP responds with a 200OK with SDP that includes both G.711 and G.729. As the PBX does not have hardware or licensing to support G.729 it should negotiate G.711 (my understanding) but accepts the offered G.729 causing a loss of audio. I had not wanted to include the entire SIP messaging sequence, but to clarify my post, I have added most below: Initial invite: INVITE sip:[email protected]:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.8.80:5060;branch=z9hG4bK158247504-93234096 Route: <sip:sbc-cw.ipvs.net:5060;transport=udp;lr> Max-Forwards: 26 Authorization: Digest username="N9999955R",realm="staging.ipvs.net",nonce="BroadWorksXgn85q2dbTua100dBW",uri="sip:[email protected]:5060",response="534c7ca51720db1fd4a60b266001b68e",algorithm=MD5,cnonce="523c36a1a20b13dd7ab5710edcf964d992417dad33f32a9814f29471430cc1ed",qop=auth,nc=00000001 Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE Supported: replaces From: "D.80" <sip:[email protected]>;tag=0_158177504-93234094 To: <sip:[email protected]> Call-ID: [email protected] CSeq: 3 INVITE Contact: "D.80" <sip:[email protected]:5060;transport=udp> P-Asserted-Identity: "D.80" <sip:[email protected]:5060;transport=udp> P-Preferred-Identity: "396241080" <sip:[email protected]> User-Agent: Mitel-3300-ICP 10.2.1.13 Content-Type: application/sdp Content-Length: 204 v=0 o=- 2475 2475 IN IP4 192.168.7.20 s=- c=IN IP4 192.168.7.20 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 SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.8.80:5060;branch=z9hG4bK158247504-93234096 From: "D.80" <sip:[email protected]>;tag=0_158177504-93234094 To: <sip:[email protected]> Call-ID: [email protected] CSeq: 3 INVITE Hold invite: INVITE sip:[email protected]:5060;url-cookie=SBCCW-fr7ft3pl6t5d9;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.8.80:5060;branch=z9hG4bK172037504-93234098 Max-Forwards: 70 Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE Supported: replaces From: "D.80" <sip:[email protected]>;tag=0_158177504-93234094 To: <sip:[email protected]>;tag=1839278173-1304385963032 Call-ID: [email protected] CSeq: 4 INVITE Contact: "D.80" <sip:[email protected]:5060;transport=udp> Content-Length: 0 Hold OK with SDP (incoming from ISP) This is sent 3 times. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.8.80:5060;branch=z9hG4bK172037504-93234098 From: "D.80" <sip:[email protected]>;tag=0_158177504-93234094 To: <sip:[email protected]>;tag=1839278173-1304385963032 Call-ID: [email protected] CSeq: 4 INVITE Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY Supported: Accept: application/media_control+xml,application/sdp Contact: <sip:[email protected]:5060;url-cookie=SBCCW-fr7ft3pl6t5d9;transport=udp> Content-Type: application/sdp Content-Length: 234 v=0 o=BroadWorks 13783 2 IN IP4 192.168.175.132 s=- c=IN IP4 10.2.1.108 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 ACK (From PBX to ISP) ACK sip:[email protected]:5060;url-cookie=SBCCW-fr7ft3pl6t5d9;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.8.80:5060;branch=z9hG4bK174147504-93234099 Max-Forwards: 70 From: "D.80" <sip:[email protected]>;tag=0_158177504-93234094 To: <sip:[email protected]>;tag=1839278173-1304385963032 Call-ID: [email protected] CSeq: 4 ACK Contact: "D.80" <sip:[email protected]: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 When the call is retrieved from 'hold' with another re-invite, the issue is resolved as the phone natively supports G.729. Hope this clears any confusion in the original post, an apologise again for the confusion. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
