RE: [reSIProcate] Question for how to handle 491 message from SIPserver
Can you explain why the 481 happens? And why the random glare timers
don't allow the reinvite to eventually succeed?
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Wenwei Xu
> Sent: Friday, March 31, 2006 11:28 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Question for how to handle 491 message from
> SIPserver
>
> An onGlare callback would be highly appreciated. So the UA can either
take
> the default action or do something else by overriding the function.
>
> Thanks very much!
>
> Wenwei
>
> -----Original Message-----
> From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Sent: Friday, March 31, 2006 10:35 AM
> To: 'Wenwei Xu'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Question for how to handle 491 message from
SIP
> server
>
> The timers should be random so that it isn't likely to happen again.
I
> don't really understand what causes the 481 message - unless the
session
> timer expires and one end kills the dialog.
>
> All that being said - we could add an onGlare callback, with the
default
> action being the current code. I'm just not sure I understand the
need.
>
> Scott
>
> -----Original Message-----
> From: Wenwei Xu [mailto:wxu@xxxxxxxxxxxxx]
> Sent: Friday, March 31, 2006 10:08 AM
> To: 'Scott Godin'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Question for how to handle 491 message from
SIP
> server
>
> You are right that they both resend the REINVITES after the Glare
timer
> expires. But they also enter a racing condition, so the SIP server
keeps
> sending back 491 message and after a few cycles the SIP server will
send
> 481
> message to terminate the call.
>
> Per protocol 14.1, it is true that a UAC should start a timer when it
> receives a 491 response, but it doesn't have to attempt the re-INVITE
> unless
> it still desires for that session modification to take place. In our
case,
> the UAC definitely doesn't desire for the session modification to take
> place
> since it is in a racing condition.
>
> -----Original Message-----
> From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Sent: Friday, March 31, 2006 9:17 AM
> To: 'Wenwei Xu'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Question for how to handle 491 message from
SIP
> server
>
> Why will the call be disconnected? They should both just resend the
> REINVITES after the Glare timer expires.
>
> -----Original Message-----
> From: Wenwei Xu [mailto:wxu@xxxxxxxxxxxxx]
> Sent: Thursday, March 30, 2006 5:39 PM
> To: 'Scott Godin'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Question for how to handle 491 message from
SIP
> server
>
> If this is the case, then if two UAC's hold the call(send Invite
message)
> exactly at the same time the call will be disconnected involuntarily.
> Should
> this be allowed?
>
> Thanks,
> Wenwei Xu
>
> -----Original Message-----
> From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Sent: Thursday, March 30, 2006 3:11 PM
> To: Wenwei Xu; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] Question for how to handle 491 message from
SIP
> server
>
> Here is a comment directly from the code.
> // RFC3261 section 14.1
> // If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
> timer
> with // a value T chosen as follows:
> // 1. If the UAC is the owner of the Call-ID of the dialog ID, T has
a
> randomly // chosen value between 2.1 and 4 seconds in units of 10 ms.
> // 2. If the UAC is not the owner of the Call-ID of the dialog ID, T
has
> a
> // randomly chosen value of between 0 and 2 seconds in units of 10
ms.
>
> Scott
>
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Wenwei
> Xu
> Sent: Thursday, March 30, 2006 2:38 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] Question for how to handle 491 message from SIP
> server
>
> When two calling parties try to hold the call (send an Invite message)
> simultaneously, the SIP server will send 491 message (pending request)
to
> both parties. Then InviteSession::start491Timer() will get called.
After
> that, the two UA's can't hold/unhold anymore but wait till timeout by
the
> SIP server (a 481 message). Is this the right way or shall we
implement a
> 491 message handler in the reciprocate stack library such that the UA
can
> have some control when this happens?
>
> Thanks a lot.
>
> Wenwei Xu
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel