RE: [reSIProcate] Question for how to handle 491 message from SIP server
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