vinodh kumar wrote:
> Paul,
>
> Scenario:
>
> A invites B, B answers with inactive media, and A ACKs this.
>
> Question was, what A is supposed to do, should it terminate the dialog with
> BYE or wait for re-invite from B?
>
> I was not aware of "start on hold" scenario. Where it would be useful?
There is no such published scenario that I know of, but it makes sense.
This could be exactly what you might see if you were answered by an IVR
that does DTMF in the signaling path, and then transfers the call. Or it
could simply be somebody that answers with MoH because they are too busy
to talk to you yet.
If you would accept being put on hold after the call is answered, why
wouldn't you accept being put on hold *when* the call is answered?
Whether you want to reject or accept the call is your business, but if
you have a human operating your phone you would probably be better off
to let him apply the policy, rather than you.
Its a harder call if B accepts the call with a 200 but *refuses* all the
media. But I think I would still leave it to the user in that case too.
To the user that would probably look the same as the inactive case.
Paul
> Thanks,
> Vinodh
>
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 30, 2008 5:57 PM
> To: vinodh kumar
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Query on offer/answer model
>
>
>
> vinodh kumar wrote:
>> All,
>>
>> It's query on offer/answer model.
>>
>> Consider the below case
>>
>> UAC sends Invite with offer, UAS answers with inactive media and
>> immediately sends re-invite with sendrecv media(for some strange reason).
>
> Just to be clear:
>
> A invites B, B answers with inactive media, and A ACKs this.
> Then B reinvites A, offering sendrecv media.
>
> Right?
>
>> What should be the desired behavior at UAC side?.
>
> You mean what should A do when it gets the reinvite? (Its then the UAS.)
>
>> Should it terminate the call after sending ACK, or should it stay in
>> media path hoping re-negotiation will take place.
>
> Why is there a question? A started out wanting sendrecv media. It was bid
> down to inactive. Now it is being offered what it wanted. Why would it not
> accept this and be happy?
>
> This is just a "start on hold" the "go off hold" scenario that happens
> quickly. Why is it different than if some time passed before the reinvite?
>
>> Definitely it is the way you implement it, but I was just wondering if
>> RFC talks anything about it some where.
>
> Definitely this is the way *who* implements it?
>
> Paul
>
>> Let me know your thoughts on this and how UAC should react in this
>> condition.
>>
>> Thanks,
>> Vinodh
>>
>> Please do not print this email unless it is absolutely necessary.
>>
>> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments.
>> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>> www.wipro.com
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted by this
> email.
>
> www.wipro.com
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
