RE: [reSIProcate] Question for how to handle 491 message from SIPserver
I know this rarely happens, but it can happen. This is how it happens:
1) UA1 and UA2 send re-INVITE to each other at the same time.
2) SIP server will then send the 491 response to both UA1 and UA2.
3) When UA1 and UA2 get the 491 response they will start the Glare timer.
4) For some reason both Glare timer expire at the same time.
5) Then UA1 and UA2 will send re-INVITE again at the same time
unfortunately.
6) SIP server will the send the 491 response again to both UA1 and UA2.
7) UA1 and UA2 will start a new Glare timer and send re-INVITE when the
timers expire.
8) After a few cycles (2 minutes), the owner of the call will send out a BYE
request (timeout) to the SIP server.
9) After that, UA1 and UA2 still sends re-INVITE, and then the SIP server
will send the 481 response to both UA1 and UA2.
There is definite a bug in step 9), because once a UA sends a BYE it should
not send re-INVITE, per the protocol. There could be a problem in step 4)
too - UA1 and UA2 generate the same random number for the timer expire time.
Wenwei
-----Original Message-----
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Friday, March 31, 2006 11:30 AM
To: Wenwei Xu; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: 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