To hold the call you must send a re-INVITE to the same DIALOG ( it means same callid , to-tag and from-tag)
And you must inform b-side that sdp has changed ( incrementing o=- 7369 7369 ) and you must send a=inactive INVITE sip:hexxvolt...@10.48.6.189:3414;tgrp=CGR01REM;trunk-context=volte.com SIP/2.0 Contact: <sip:hexxvolt...@10.48.6.189:3414> Content-Type: application/sdp Call-ID: ed3808a9a75ba99927178...@aqb27u6u CSeq: 1 INVITE From: <sip:hexxvolt...@volte.com>;tag=5992.622211750.2 To: "hexxvolte08" <sip:hexxvolt...@volte.com>;tag=jgCZU.f9.f.g4WUX Max-Forwards: 70 Via: SIP/2.0/UDP 10.48.6.189:3414;branch=z9hG4bK622211750.5992.4 Route: <sip:aaqab8ghcaabpaaaa+aaaj...@10.48.132.147:5060;yop=00.00.2CB1030E.000 0.42F2;lr> Content-Length: 206 v=0 o=- 7369 7369 IN IP4 10.52.39.102 s=- IPSL c=IN IP4 10.52.39.102 t=0 0 m=audio 10002 RTP/AVP 96 104 a=rtpmap:96 AMR/8000 a=rtpmap:104 telephone-event/8000 a=ptime:20 a=maxptime:20 a=inactive To resume (a=sendrecv) : INVITE sip:hexxvolt...@10.48.6.189:3414;tgrp=CGR01REM;trunk-context=volte.com SIP/2.0 Contact: <sip:hexxvolt...@10.48.6.189:3414> Content-Type: application/sdp Call-ID: ed3808a9a75ba99927178...@aqb27u6u CSeq: 3 INVITE From: <sip:hexxvolt...@volte.com>;tag=5992.622211750.2 To: "hexxvolte08" <sip:hexxvolt...@volte.com>;tag=jgCZU.f9.f.g4WUX Max-Forwards: 70 Via: SIP/2.0/UDP 10.48.6.189:3414;branch=z9hG4bK622211750.5992.7 Route: <sip:aaqab8ghcaabpaaaa+aaaj...@10.48.132.147:5060;yop=00.00.2CB1030E.000 0.42F2;lr> Content-Length: 208 Proxy-Authorization: Digest username="hexxvolte09",realm="volte.com",nonce="5cd5eb9eeedb658c51b2b14c 855bcede",uri="sip:hexxvolt...@10.48.6.189:3414;tgrp=CGR01REM;trunk-cont ext=volte.com",response="59039dfb91bc83ebaf2fc5651ead1711" v=0 o=- 10375 10375 IN IP4 10.52.39.102 s=- IPSL c=IN IP4 10.52.39.102 t=0 0 m=audio 10002 RTP/AVP 96 104 a=rtpmap:96 AMR/8000 a=rtpmap:104 telephone-event/8000 a=ptime:20 a=maxptime:20 a=sendrecv Best Regards, Valdemar Pavesi 6000 Connection Drive Irving, TX 75039, USA Mob: +1 561 699 5166 valdemar.pav...@nsn.com http://www.nokiasiemensnetworks.com/ -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Verma Sunil Sent: Sunday, September 19, 2010 11:06 PM To: Paul Kyzivat; anand madhab Cc: Sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] sdp missing m line Hi Anand, I agree with Paul. I am not sure why you have to put SDP and not m-line for Audio? Do you want to share other media attributes and not Audio? As per spec there could be many ways to initiate a call with hold attributes. You can use the rules mentioned below by Paul in offer as well. Please refer to Offer Answer RFC 3264 Section 5.1(offer) and 6.1(Answer) for Unicast Sessions Regards Sunil Verma -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat Sent: Saturday, September 18, 2010 2:26 AM To: anand madhab Cc: Sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] sdp missing m line On 9/17/2010 7:45 AM, anand madhab wrote: > Hi, If m line is missing in invite request and 180, 200 response then what > will be senario ? > I dont understand the case, I mean i want to make a call with initially > putting a person in hold ? please explain > does caller need to reject the call Your question isn't entirely clear. Can you show call flow? I am guessing that the INVITE has SDP with one m-line, and the response has SDP with no m-line ??? If so, I would expect the caller to send BYE and drop the call. The answer SDP must have the same number of m-lines as the offer. We don't usually specify behavior for non-conforming cases (which this is), so the caller isn't *required* to send a BYE. But behavior after that is undefined. Are you implementing the UAS, and wanting to prevent media from flowing immediately as the call is established? You can do a number of things, depending on exactly what you want to happen: - you can respond with an answer with matching m-line, with real address and port, and include an a=sendonly or a=inactive to prevent media from flowing to you. You have indicated that you are willing to use this media, but not yet. In case of RTP-based media, *RTCP* will still flow. - you can respond with an answer with matching m-line, and a non-zero port, but with an address (c=) of 0.0.0.0. This is similar to prior, except nothing will flow to you. - you can respond with an answer with matching m-line, with a zero port. This says you are rejecting the use of this media, but haven't rejected the call. This is valid in principle, but its likely to upset some UAs, because they don't know what they are supposed to do. Paul _______________________________________________ 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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
