Look at the offeranswer draft for a discussion of this.
While your option 1 will "work" in some cases, it won't always work.
Specifically, if both sides put the call on hold, then there will be no
way to get off hold.
The solution is to always offer the directionality your end wants,
without regard to what you think the other end wants. The other end can
take care of its needs in the answer.
Thanks,
Paul
On 1/4/2011 8:23 AM, Nataraju A.B wrote:
> We should proceed with option-1. In this case Re-Invite with out SDP leads
> to delayed media negotiation...
>
> On Tue, Jan 4, 2011 at 6:36 PM, Chandan Kumar<chandan_28...@yahoo.com>wrote:
>
>> Hi ,
>>
>> Thanks for the responses. Even I thougt the same.
>>
>> Lets say for the same case mean for unholding the call , if we get
>> Re-inivte with no SDp from B2BuA . How SIP entity should respond ( SIP
>> entity is in Held state).
>>
>> Does SIP entity should respond with the Current state with 200 ok putting
>> media attribute as a=Inactive
>>
>> (or)
>>
>> For Reinvite regardless of the state we need to respond in 200 Ok with
>> media a=sendrecv?
>>
>> This is issue faced by on of our customers. Our software always respond
>> with curretn state for Re-Invite Message.
>>
>> But for the same case the X-lite Phone responds with a=sendrecv ?
>>
>>
>> How to deal with this issue& which is correct option .
>>
>>
>> Best Regards,
>> Chandan.
>>
>> --- On Tue, 4/1/11, Harlin Dyvia Helina Sathianathan<
>> harlin.sathianat...@aricent.com> wrote:
>>
>>
>> From: Harlin Dyvia Helina Sathianathan<harlin.sathianat...@aricent.com>
>> Subject: RE: [Sip-implementors] SIP Call/Hold Scenario
>> To: "Chandan Kumar"<chandan_28...@yahoo.com>, "
>> sip-implementors@lists.cs.columbia.edu"<
>> sip-implementors@lists.cs.columbia.edu>
>> Date: Tuesday, 4 January, 2011, 6:18 AM
>>
>>
>> Hi,
>>
>> The call hold scenario looks working right but the entity in between A and
>> B should be a B2BUA. Thus B2B sends back SDP-answer with c = 0.0.0.0& a =
>> Inactive behalf of B in case of call hold, which is right.
>>
>> But in the call unhold scenario,B2B should have sent an offer to B with
>> a=sendrecv. This should be a bug with B2B.
>>
>> Regards,
>> Harlin
>>
>> -----Original Message-----
>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
>> sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Chandan Kumar
>> Sent: Monday, January 03, 2011 4:11 PM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] SIP Call/Hold Scenario
>>
>> Hi All ,
>>
>> This is an query regarding call hold scenario .
>> Two phones A,B are registered to SIP proxy. Let's say A& B are in call.
>>
>> 1.Now A holds the call by changing medi attribute in SDP to a= sendonly.
>> 2.Proxy sends signalling message Trying.
>> 3..Proxy sends 200 OK with SDP to Phone A in which media attribute set to
>> c = 0.0.0.0& a = Inactive
>> My Question is the proxy is sending 200 ok to Phone A by changing media
>> attibute.Is this correct?
>>
>> As far as my understanding Proxy should send the invite message to other
>> endpoint i.e B.
>>
>> 4.Apart from above issue ,later on proxy sends Invite with c=0.0.0.0&
>> a=Inacitve to B.
>> As usual B responds with Inacitve.
>>
>> Till here call is on Hold.
>>
>> Unhold scenario: Now call between A& B is held.
>>
>> 1.A unholds the call ,changing media attribute to a = sendrecv.
>> 2.But the proxy again changing the media attribute to a=inactive&
>> connection Ip c=0.0.0.0 sends the Invite message to Phone B.
>>
>> Why the proxy is behaving strangly? Is this a bug with proxy.
>>
>> 3.Phone responds with medai attribute a= Inactive.
>>
>> Because of these reasongs call hold/unhold is failing.
>>
>> Please let me know whether proxy behaviour is correct ot not?
>>
>> Accoring to RFC my understading is :
>> sendrecv - Used to establish a 2-way media stream.
>> recvonly - The SIP endpoint would only receive (listen mode) and not send
>> media.
>> sendonly - The SIP endpoint would only send and not receive media.
>> inactive - The SIP endpoint would neither send nor receive media.
>>
>>
>>
>>
>> Best Regards,
>> Chandan.
>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
>> for the use of the individual to whom it is addressed. It may contain
>> privileged or confidential information and should not be circulated or used
>> for any purpose other than for what it is intended. If you have received
>> this message in error, please notify the originator immediately. If you are
>> not the intended recipient, you are notified that you are strictly
>> prohibited from using, copying, altering, or disclosing the contents of this
>> message. Aricent accepts no responsibility for loss or damage arising from
>> the use of the information transmitted by this email including damage from
>> virus."
>>
>>
>> _______________________________________________
>> 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
