[reSIProcate] Route Set problem with Update in resip 1.1 RC1
Kovar, William (Bill)
bkovar at avaya.com
Thu Mar 8 11:26:43 CST 2007
Scott,
I put your code back in and ran the scenario where I send INVITE, INVITE
w/Proxy-Auth and Re-Invite.
Each 200 OK updated mRouteSet
See log snip below:
------------>>>>>>>> INITIAL INVITE
![2007-03-08 16:58:24.424] <1524:RESIP:TRANSPORT> DEBUG |
transportselector.cxx:869 | Transmitting to [ V4 135.8.52.181:5060 UDP
target domain=135.8.52.181 received on: Transport: [ V4 0.0.0.0:5060 UDP
target domain=unspecified connectionId=0 ] connectionId=0 ] tlsDomain=
via [ V4 135.8.116.33:5060 UDP target domain=135.8.52.181 connectionId=0
]
INVITE sip:76800 at avaya.com SIP/2.0
Via: SIP/2.0/UDP
135.8.116.33:5060;branch=z9hG4bK-d8754z-7034f95d557c5006-1---d8754z-;rpo
rt
Max-Forwards: 70
Contact: <sip:56000 at 135.8.116.33:5060>
To: <sip:76800 at avaya.com>
From: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=e0733a11
Call-ID: NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY
User-Agent: AvSIP 1.04.2
Content-Length: 0
-------------->>>>>>>>>>> INVITE w/Proxy-Auth
![2007-03-08 16:58:24.471] <1524:RESIP:TRANSPORT> DEBUG |
transportselector.cxx:869 | Transmitting to [ V4 135.8.52.181:5060 UDP
target domain=135.8.52.181 received on: Transport: [ V4 0.0.0.0:5060 UDP
target domain=unspecified connectionId=0 ] connectionId=0 ] tlsDomain=
via [ V4 135.8.116.33:5060 UDP target domain=135.8.52.181 connectionId=0
]
INVITE sip:76800 at avaya.com SIP/2.0
Via: SIP/2.0/UDP
135.8.116.33:5060;branch=z9hG4bK-d8754z-e154f11ec7627f48-1---d8754z-;rpo
rt
Max-Forwards: 70
Contact: <sip:56000 at 135.8.116.33:5060>
To: <sip:76800 at avaya.com>
From: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=e0733a11
Call-ID: NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY
Proxy-Authorization: Digest
username="56000",realm="avaya.com",nonce="MTE3MzQwNzE0NjpTREZTZXJ2ZXJTZW
NyZXRLZXk6MTkzOTg5MjA3NA==",uri="sip:76800 at avaya.com",response="dbb73584
19477f367f4a07816d2cc48c",algorithm=MD5
User-Agent: AvSIP 1.04.2
Content-Length: 0
-------------------------->>>>> 200 OK w/mRouteSet being assigned
![2007-03-08 16:58:24.674] <808:RESIP:DUM> DEBUG | DialogId.cxx:50 |
DialogId::DialogId:
NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.-e0733a11-804697e7eddddb1f12
046f94dc00
![2007-03-08 16:58:24.674] <808:RESIP:DUM> DEBUG | DialogSet.cxx:428 |
Found matching dialog mClientSubscriptions(0), mServerSubscriptions(0)
for
SIP/2.0 200 OK
Via: SIP/2.0/UDP
135.8.116.33:5060;received=135.8.116.33;branch=z9hG4bK-d8754z-e154f11ec7
627f48-1---d8754z-;rport=5060
Record-Route: <sip:135.8.83.172:5061;lr;transport=tls>
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: "meet me 1"<sip:76800 at avaya.com:5061;transport=tls>;isfocus
To: <sip:76800 at avaya.com>;tag=804697e7eddddb1f12046f94dc00
From: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=e0733a11
Call-ID: NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.
CSeq: 2 INVITE
Session-Expires: 240;refresher=uas
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER,
OPTIONS
Content-Type: application/sdp
Server: Avaya CM/R013x.01.2.632.1
Supported: 100rel, timer, replaces, join, histinfo
P-Asserted-Identity: "meet me 1" <sip:76800 at avaya.com:5061>
Content-Length: 202
v=0
o=- 1 2 IN IP4 135.8.83.172
s=-
c=IN IP4 135.8.83.133
t=0 0
m=audio 42532 RTP/AVP 0 18 127
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
![2007-03-08 16:58:24.674] <808:RESIP:DUM> DEBUG | Dialog.cxx:315 |
Dialog::dispatch: SipResp: 200 tid=e154f11ec7627f48 cseq=INVITE
contact=76800 at avaya.com:5061 / 2 from(wire)
![2007-03-08 16:58:24.674] <808:RESIP:DUM> INFO | Dialog.cxx:582 |
############# Setting Route Set
![2007-03-08 16:58:24.674] <808:RESIP> DEBUG | sipmessage.cxx:963 |
SipMessage::getContents: application/sdp
![2007-03-08 16:58:24.674] <808:RESIP> DEBUG | helper.cxx:2035 | Got
sdp
![2007-03-08 16:58:24.674] <808:RESIP:DUM> INFO |
InviteSession.cxx:2067 | Transition UAC_Early -> UAC_Answered
![2007-03-08 16:58:24.674] <808:RESIP:APP> INFO | UserAgent.cpp:901 |
sip:76800 at avaya.com: CUserAgent::onOffer(ISH SDP) on session 23 -
SipResp: 200 tid=e154f11ec7627f48 cseq=INVITE
contact=76800 at avaya.com:5061
----------------------------->>>>> Next Invite (3)
![2007-03-08 16:58:34.283] <1524:RESIP:TRANSPORT> DEBUG |
transportselector.cxx:869 | Transmitting to [ V4 135.8.52.181:5060 UDP
target domain=135.8.52.181 received on: Transport: [ V4 0.0.0.0:5060 UDP
target domain=unspecified connectionId=0 ] connectionId=0 ] tlsDomain=
via [ V4 135.8.116.33:5060 UDP target domain=135.8.52.181 connectionId=0
]
INVITE sip:76800 at avaya.com:5061;transport=tls SIP/2.0
Via: SIP/2.0/UDP
135.8.116.33:5060;branch=z9hG4bK-d8754z-f26e897b7b668a40-1---d8754z-;rpo
rt
Max-Forwards: 70
Route: <sip:135.8.52.181:5060;lr>
Route: <sip:135.8.83.172:5061;lr;transport=tls>
Contact: <sip:56000 at 135.8.116.33:5060>
To: <sip:76800 at avaya.com>;tag=804697e7eddddb1f12046f94dc00
From: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=e0733a11
Call-ID: NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.
CSeq: 3 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY
Content-Type: application/sdp
Proxy-Authorization: Digest
username="56000",realm="avaya.com",nonce="MTE3MzQwNzE0NjpTREZTZXJ2ZXJTZW
NyZXRLZXk6MTkzOTg5MjA3NA==",uri="sip:76800 at avaya.com:5061;transport=tls"
,response="611b2402bbc088a03334ce5ed24221bf",algorithm=MD5
User-Agent: AvSIP 1.04.2
Content-Length: 151
v=0
o=- 1 12 IN IP4 135.8.83.172
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 42516 RTP/AVP 0 127
a=rtpmap:0 PCMU/8000
a=rtpmap:127 telephone-event/8000
--------------------->>>>>>>>>>>>>> 200 OK (3) set mRouteSet again!!
![2007-03-08 16:58:34.345] <808:RESIP:DUM> DEBUG | DialogId.cxx:50 |
DialogId::DialogId:
NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.-e0733a11-804697e7eddddb1f12
046f94dc00
![2007-03-08 16:58:34.345] <808:RESIP:DUM> DEBUG | DialogSet.cxx:428 |
Found matching dialog mClientSubscriptions(0), mServerSubscriptions(0)
for
SIP/2.0 200 OK
Via: SIP/2.0/UDP
135.8.116.33:5060;received=135.8.116.33;branch=z9hG4bK-d8754z-f26e897b7b
668a40-1---d8754z-;rport=5060
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: " CONFERENCE
2"<sip:76800 at avaya.com:5061;transport=tls>;isfocus
To: <sip:76800 at avaya.com>;tag=804697e7eddddb1f12046f94dc00
From: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=e0733a11
Call-ID: NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.
CSeq: 3 INVITE
Session-Expires: 240;refresher=uas
Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE, NOTIFY, REFER,
OPTIONS
Content-Type: application/sdp
Server: Avaya CM/R013x.01.2.632.1
Supported: 100rel, timer, replaces, join, histinfo
Content-Length: 150
v=0
o=- 1 3 IN IP4 135.8.83.172
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 42532 RTP/AVP 0 127
a=rtpmap:0 PCMU/8000
a=rtpmap:127 telephone-event/8000
![2007-03-08 16:58:34.345] <808:RESIP:DUM> DEBUG | Dialog.cxx:315 |
Dialog::dispatch: SipResp: 200 tid=f26e897b7b668a40 cseq=INVITE
contact=76800 at avaya.com:5061 / 3 from(wire)
![2007-03-08 16:58:34.345] <808:RESIP:DUM> DEBUG |
ClientAuthManager.cxx:41 | ClientAuthManager::handle: transitioning
NTlhOWI1MTZmNDIzMWZiZjlkZmYzN2VlY2U0ZTAwNDI.-e0733a11to cached
![2007-03-08 16:58:34.345] <808:RESIP:DUM> DEBUG |
ClientAuthManager.cxx:193 | ClientAuthManager::RealmState::transition
from cached to cached
![2007-03-08 16:58:34.345] <808:RESIP:DUM> INFO | Dialog.cxx:582 |
############# Setting Route Set
![2007-03-08 16:58:34.345] <808:RESIP> DEBUG | sipmessage.cxx:963 |
SipMessage::getContents: application/sdp
![2007-03-08 16:58:34.345] <808:RESIP> DEBUG | helper.cxx:2035 | Got
sdp
![2007-03-08 16:58:34.345] <808:RESIP:DUM> INFO |
InviteSession.cxx:2067 | Transition InviteSession::SentReinvite ->
InviteSession::Connected
Bill Kovar
bkovar at avaya.com
Avaya, Inc.
(732) 852-2609
_____
From: Scott Godin [mailto:slgodin at icescape.com]
Sent: Thursday, March 08, 2007 12:00 PM
To: Scott Godin; Byron Campen
Cc: Kovar, William (Bill); Robert Sparks;
resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] Route Set problem with Update in
resip 1.1 RC1
Actually I'm convinced that the only way this can happen is if
the resip application re-uses CSeq's in mid-dialog requests - not
garbage from the wire.
Scott
From: Scott Godin
Sent: Thursday, March 08, 2007 11:39 AM
To: 'Byron Campen'
Cc: 'Kovar, William (Bill)'; 'Robert Sparks';
'resiprocate-devel at list.resiprocate.org'
Subject: RE: [reSIProcate] Route Set problem with Update in
resip 1.1 RC1
Well technically we can set the RouteSet on a 1xx and then later
update on a 2xx. We could add a flag that gets set to true when we set
the routeset due to 2xx response. I think that would work. I'll look
into this.
From: Byron Campen [mailto:bcampen at estacado.net]
Sent: Thursday, March 08, 2007 11:25 AM
To: Scott Godin
Cc: Kovar, William (Bill); Robert Sparks;
resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] Route Set problem with Update in
resip 1.1 RC1
Maybe we ought to just put in a bool that gets set to
true when the Record-Routes are first set. That would be nice and robust
against garbage from the wire, I think.
Best regards,
Byron Campen
Strange. Every sent re-invite should have a different CSeq than
creator->getLastRequest() (request used to create the UAC dialog) - so
this code should NOT update the route set. How are you sending
re-invites?
Scott
From: Kovar, William (Bill) [mailto:bkovar at avaya.com]
Sent: Wednesday, March 07, 2007 6:28 PM
To: Robert Sparks; Byron Campen; Scott Godin
Cc: resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] Route Set problem with Update in
resip 1.1 RC1
Robert, Byron, Scott,
The problem I am seeing is actually not directly (I think),
related to the Update. Additional digging seems to point to the bug I
had found a while back (see thread: Question about Record-Route headers
on re-Invite).
The Update msg gets sent a 200 OK correctly. But my ensuing
re-invite, w/2 RR, is 200 OK's w/1 RR, and the ACK only uses 1 RR. I
believe that the 200 OK to the re-invite is causing DUM to over-write
the mRouteSet for the session.
Scott Godin put a fix in for this problem but I believe the fix
is broken because EVERY sent Invite's 200 OK is over-writing the route
set.
The fix in Dialog.cxx line 561 is:
BaseCreator* creator = mDialogSet.getCreator();
if (creator &&
(creator->getLastRequest()->header(h_CSeq).sequence() ==
response.header(h_CSeq).sequence()) && code >=200 && code < 300)
{
if (response.exists(h_RecordRoutes))
{
mRouteSet = response.header(h_RecordRoutes).reverse();
}
}
I don't know what mDialog.getCreator() is pointing to, but this
code is getting executed again for an already established session.
Bill Kovar
bkovar at avaya.com <mailto:bkovar at avaya.com>
Avaya, Inc.
(732) 852-2609
_____
From: Robert Sparks [mailto:rjsparks at nostrum.com]
Sent: Wednesday, March 07, 2007 5:35 PM
To: Byron Campen
Cc: Kovar, William (Bill);
resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] Route Set problem with Update
in resip 1.1 RC1
Ok - so I dug and have to concede that I find no
normative requirement to echo the RR in the 200
to a mid-dialog request (on today's dig anyhow).
Here is what we have assuming I didn't miss something:
12.1.1.1 first paragraph contains the requirement to
echo what you see (arguably, you could
claim that this applies only to messages that create a
dialog)
12.2 contains the text telling you that RR may show up
mid-dialog, but you don't update the route set.
Bill - for your purposes, that text in 12.2 should give
you the path out of your original question. It doesn't
_matter_ what bits get put those responses - you are
supposed to ignore them as an endpoint.
12.2.2 sends you off to 8.2 once you've figured out this
is a mid-dialog request (and has
some of the reconstituting state text btw). I am willing
to bet (based on memory, take it for what it's worth)
that the text there at one point contained the reflect
the RR and it got shuffled out during the 3261
restructuring editing.
So where does that leave us? We _could_ decide to not
return any RR at all in these mid-dialog requests
without violating spec. (We could also populate them
with frogs as long as we can make them syntactically
valid without violating spec).
I'll argue that most of the world will expect to see
what was contained in the request reflected back to them
and we'll keep our interoperability level highest by
doing that (until we have an opportunity to clean the
spec with respect to this).
RjS
On Mar 7, 2007, at 4:11 PM, Byron Campen wrote:
By the way, is there specific normative text for this? I
tried finding some, but I never found a section that specified the UAS
behavior vis-a-vis Record-Routes for in-dialog requests (in 3261
anyway).
Best regards,
Byron Campen
You are correct that the route set doesn't change. But
that has nothing to do with
the contents of the Record-Route header field in a
mid-dialog transaction.
We are still required by the spec to reflect in the
response exactly what we receive in the request.
It does not change our route set. It will not change the
other ends route set. (The endpoints are
_required_ to ignore the Record-Route header field in
mid-dialog transactions).
So there are many wasted bits, but that is what the spec
requires.
How did the spec get into such a messy place? There was
an attempt at one point
(mostly led by Henning) to make it so that endpoints
could "reconstitute" dialog state
after rebooting by pulling some mid-dialog message out
of the ether and filling in all the blanks.
To support that effort, a SHOULD requirement on proxies
to add Record-Route to mid-dialog
requests was added. And, in a twist of irony, the very
same conversations reinforced the idea
that the route set must never change (shooting down the
suggestion that we record-route
every request, we might as well make the route set
updateable). ((And this is one of the arguments
I'm still bitter about losing btw).
The upshot is: The stack is doing what it's supposed to
do.
RjS
On Mar 7, 2007, at 3:36 PM, Kovar, William ((Bill))
wrote:
The basic rule is:
Once the route set is computed (from an initial INVITE
or response that creates a dialog) it doesn't change.
Only the remote target can change.
So this in-dialog Update shouldn't be doing this....
Bill Kovar
bkovar at avaya.com <mailto:bkovar at avaya.com>
Avaya, Inc.
(732) 852-2609
_____
From: Byron Campen [mailto:bcampen at estacado.net
<mailto:bcampen at estacado.net> ]
Sent: Wednesday, March 07, 2007 4:31 PM
To: Kovar, William (Bill)
Cc: resiprocate-devel at list.resiprocate.org
<mailto:resiprocate-devel at list.resiprocate.org>
Subject: Re: [reSIProcate] Route Set problem
with Update in resip 1.1 RC1
This is interesting. I do not think it would be
correct to change the Record-Route stack to reflect the Route set in the
dialog. Obviously something in the middle is confused if this happens,
and changing the Record-Route stack in the response is liable to confuse
it even further. Both endpoints should just ignore the Record-Route
header-field-values entirely, I think.
Any other opinions?
Best regards,
Byron Campen
There seems to be another problem with Record
Route processing.
After an established dialog, an Update is
received that runs through Helper::makeResponse() to build a 200 msg
that does not contain the correct Route Set.
I had found this error in a different scenario,
i.e. a response, which is fixed. Now I see this in an Update, i.e. a
request.
I believe the problem is at Helper.cxx line 410
Here's a log snip, correct route set in ACK in
blue, bad route set in 200 OK in red for same call-id:
![2007-03-07 20:14:53.258]
<2952:RESIP:TRANSPORT> DEBUG | TransportSelector.cxx:869 | Transmitting
to [ V4 135.8.52.181:5060 UDP target domain=135.8.52.181 received on:
Transport: [ V4 0.0.0.0:5060 UDP target domain=unspecified
connectionId=0 ] connectionId=0 ] tlsDomain= via [ V4 135.8.116.33:5060
UDP target domain=135.8.52.181 connectionId=0 ]
ACK sip:76800 at avaya.com <mailto:76800 at avaya.com>
:5061;transport=tls SIP/2.0
Via: SIP/2.0/UDP
135.8.116.33:5060;branch=z9hG4bK-d8754z-b20c1e5c1c57e971-1---d8754z-;rpo
rt
Max-Forwards: 70
Route: <sip:135.8.52.181:5060;lr>
Route: <sip:135.8.83.172:5061;lr;transport=tls>
Contact: <sip:56000 at 135.8.116.33
<mailto:56000 at 135.8.116.33> :5060>
To: <sip:76800 at avaya.com
<mailto:76800 at avaya.com> >;tag=0945f2f40dddb181b46f94dc00
From: "IC 7.1 B2B"<sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 2 ACK
Content-Type: application/sdp
Proxy-Authorization: Digest
username="56000",realm="avaya.com",nonce="MTE3MzMzMTA4NTpTREZTZXJ2ZXJTZW
NyZXRLZXk6NzQ1MTU0ODc4",uri="sip:76800 at avaya.com
<mailto:76800 at avaya.com>
",response="e1bdfe0882c087d5334812ad288f7c60",algorithm=MD5
User-Agent: AvSIP 1.04.2
Content-Length: 202
v=0
o=- 1 2 IN IP4 135.8.83.172
s=-
c=IN IP4 135.8.83.133
t=0 0
m=audio 36456 RTP/AVP 0 18 127
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:127 telephone-event/8000
![2007-03-07 20:14:53.258]
<2952:RESIP:TRANSPORT> DEBUG | Transport.cxx:213 | Adding message to tx
buffer to: [ V4 135.8.52.181:5060 UDP target domain=135.8.52.181
received on: Transport: [ V4 0.0.0.0:5060 UDP target domain=unspecified
connectionId=0 ] connectionId=0 ]
![2007-03-07 20:14:53.305]
<2952:RESIP:TRANSPORT> DEBUG | Transport.cxx:287 | incoming from: [ V4
135.8.52.181:32796 UDP target domain=unspecified received on: Transport:
[ V4 0.0.0.0:5060 UDP target domain=unspecified connectionId=0 ]
connectionId=0 ]
![2007-03-07 20:14:53.305]
<2952:RESIP:TRANSACTION> DEBUG | TransactionUser.cxx:66 | Checking if
SipReq: UPDATE56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=03950393A79343D4439ec3.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire) is for me
![2007-03-07 20:14:53.305]
<2952:RESIP:TRANSACTION> DEBUG | TransactionUser.cxx:71 | Checking
rule...
![2007-03-07 20:14:53.305]
<2952:RESIP:TRANSACTION> DEBUG | MessageFilterRule.cxx:70 | Matching
rule for:
UPDATE sip:56000 at 135.8.116.33
<mailto:56000 at 135.8.116.33> :5060 SIP/2.0
Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0
Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00
Max-Forwards: 69
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: " CONFERENCE 2"<sip:76800 at avaya.com
<mailto:76800 at avaya.com> :5061;transport=tls>;isfocus
To: "IC 7.1 B2B" <sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
From: sip:76800 at avaya.com
<mailto:76800 at avaya.com> ;tag=0945f2f40dddb181b46f94dc00
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 1 UPDATE
Session-Expires: 240;refresher=uac
Min-SE: 240
Allow: INVITE, CANCEL, BYE, ACK, PRACK,
SUBSCRIBE, NOTIFY, REFER, OPTIONS
Supported: 100rel, timer, replaces, join,
histinfo
User-Agent: Avaya CM/R013x.01.2.632.1
Content-Length: 0
![2007-03-07 20:14:53.383]
<2952:RESIP:TRANSACTION> DEBUG | MessageFilterRule.cxx:241 | MSG User =
56000
![2007-03-07 20:14:53.383]
<2952:RESIP:TRANSACTION> DEBUG | MessageFilterRule.cxx:252 | List USER
= 56000
![2007-03-07 20:14:53.383]
<2952:RESIP:TRANSACTION> DEBUG | TransactionUser.cxx:74 | Match!
![2007-03-07 20:14:53.383] <2952:RESIP> DEBUG
| Helper.cxx:372 | Helper::makeResponse(SipReq:
UPDATE56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire) code=100 reason=
![2007-03-07 20:14:53.383]
<2952:RESIP:TRANSACTION> DEBUG | TimerQueue.cxx:85 | Adding timer:
Timer Trying tid=83A503034493935543998a.0 ms=3500
![2007-03-07 20:14:53.383]
<2952:RESIP:TRANSACTION> DEBUG | TransactionState.cxx:1852 | Send to
TU: TU: DialogUsageManager size=0
UPDATE sip:56000 at 135.8.116.33
<mailto:56000 at 135.8.116.33> :5060 SIP/2.0
Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0
Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00
Max-Forwards: 69
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: " CONFERENCE 2"<sip:76800 at avaya.com
<mailto:76800 at avaya.com> :5061;transport=tls>;isfocus
To: "IC 7.1 B2B" <sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
From: sip:76800 at avaya.com
<mailto:76800 at avaya.com> ;tag=0945f2f40dddb181b46f94dc00
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 1 UPDATE
Session-Expires: 240;refresher=uac
Min-SE: 240
Allow: INVITE, CANCEL, BYE, ACK, PRACK,
SUBSCRIBE, NOTIFY, REFER, OPTIONS
Supported: 100rel, timer, replaces, join,
histinfo
User-Agent: Avaya CM/R013x.01.2.632.1
Content-Length: 0
![2007-03-07 20:14:53.383] <2840:RESIP:DUM>
INFO | DialogUsageManager.cxx:1190 | Got: SipReq:
UPDATE56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
DEBUG | DialogUsageManager.cxx:1456 |
DialogUsageManager::processRequest: SipReq: UPDATE
56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
INFO | DialogUsageManager.cxx:1516 | Handling in-dialog request: SipReq:
UPDATE56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
DEBUG | DialogId.cxx:50 | DialogId::DialogId:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.-b855e212-0945f2f40dddb181b4
6f94dc00
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
DEBUG | DialogSet.cxx:428 | Found matching dialog
mClientSubscriptions(0), mServerSubscriptions(0) for
UPDATE sip:56000 at 135.8.116.33
<mailto:56000 at 135.8.116.33> :5060 SIP/2.0
Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0
Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00
Max-Forwards: 69
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: " CONFERENCE 2"<sip:76800 at avaya.com
<mailto:76800 at avaya.com> :5061;transport=tls>;isfocus
To: "IC 7.1 B2B"<sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
From: <sip:76800 at avaya.com
<mailto:76800 at avaya.com> >;tag=0945f2f40dddb181b46f94dc00
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 1 UPDATE
Session-Expires: 240;refresher=uac
Min-SE: 240
Allow: INVITE, CANCEL, BYE, ACK, PRACK,
SUBSCRIBE, NOTIFY, REFER, OPTIONS
Supported: 100rel, timer, replaces, join,
histinfo
User-Agent: Avaya CM/R013x.01.2.632.1
Content-Length: 0
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
DEBUG | Dialog.cxx:315 | Dialog::dispatch: SipReq:
UPDATE56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP> DEBUG
| Helper.cxx:372 | Helper::makeResponse(SipReq:
UPDATE56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061> / 1 from(wire) code=200 reason=
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
DEBUG | Dialog.cxx:984 | Dialog::makeResponse:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0
Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: <sip:56000>
To: "IC 7.1 B2B"<sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
From: <sip:76800 at avaya.com
<mailto:76800 at avaya.com> >;tag=0945f2f40dddb181b46f94dc00
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 1 UPDATE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE,
UPDATE, NOTIFY
Content-Length: 0
![2007-03-07 20:14:53.399] <2840:RESIP:APP>
INFO | UserAgent.cpp:2146 | sip:76800 at avaya.com <mailto:76800 at avaya.com>
CUserAgent::onReadyToSend(CISH) on session 23 - SipResp: 200
tid=83A503034493935543998a.0 cseq=UPDATE contact=56000 / 1 from(tu)
![2007-03-07 20:14:53.399] <2840:RESIP:APP>
INFO | UserAgent.cpp:2147 | NO OP
![2007-03-07 20:14:53.399] <2840:RESIP:DUM>
DEBUG | DialogUsageManager.cxx:800 | SEND:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0
Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: <sip:56000>
To: "IC 7.1 B2B"<sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
From: <sip:76800 at avaya.com
<mailto:76800 at avaya.com> >;tag=0945f2f40dddb181b46f94dc00
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 1 UPDATE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE,
UPDATE, NOTIFY
User-Agent: AvSIP 1.04.2
Content-Length: 0
![2007-03-07 20:14:53.399] <2840:RESIP> DEBUG
| SipStack.cxx:290 | SEND: SipResp: 200 tid=83A503034493935543998a.0
cseq=UPDATE contact=56000 / 1 from(tu)
![2007-03-07 20:14:53.414]
<2952:RESIP:TRANSACTION> DEBUG | TimerQueue.cxx:85 | Adding timer:
Timer J tid=83A503034493935543998a.0 ms=32000
![2007-03-07 20:14:53.414]
<2952:RESIP:TRANSPORT> DEBUG | TransportSelector.cxx:521 | Looked up
source for destination: [ V4 135.8.52.181:5060 UDP target
domain=unspecified received on: Transport: [ V4 0.0.0.0:5060 UDP target
domain=unspecified connectionId=0 ] connectionId=0 ] -> [ V4
135.8.116.33:0 UDP target domain=unspecified received on: Transport: [
V4 0.0.0.0:5060 UDP target domain=unspecified connectionId=0 ]
connectionId=0 ] sent-by=135.8.52.181 sent-port=5060
![2007-03-07 20:14:53.414]
<2952:RESIP:TRANSPORT> DEBUG | TransportSelector.cxx:869 | Transmitting
to [ V4 135.8.52.181:5060 UDP target domain=unspecified received on:
Transport: [ V4 0.0.0.0:5060 UDP target domain=unspecified
connectionId=0 ] connectionId=0 ] tlsDomain= via [ V4 135.8.116.33:5060
UDP target domain=unspecified received on: Transport: [ V4 0.0.0.0:5060
UDP target domain=unspecified connectionId=0 ] connectionId=0 ]
SIP/2.0 200 OK
Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0
Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00
Record-Route: <sip:135.8.52.181:5060;lr>
Contact: <sip:56000 at 135.8.116.33
<mailto:56000 at 135.8.116.33> :5060>
To: "IC 7.1 B2B"<sip:56000 at avaya.com
<mailto:56000 at avaya.com> >;tag=b855e212
From: <sip:76800 at avaya.com
<mailto:76800 at avaya.com> >;tag=0945f2f40dddb181b46f94dc00
Call-ID:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.
CSeq: 1 UPDATE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE,
UPDATE, NOTIFY
User-Agent: AvSIP 1.04.2
Content-Length: 0
![2007-03-07 20:14:53.414]
<2952:RESIP:TRANSPORT> DEBUG | Transport.cxx:213 | Adding message to tx
buffer to: [ V4 135.8.52.181:5060 UDP target domain=unspecified received
on: Transport: [ V4 0.0.0.0:5060 UDP target domain=unspecified
connectionId=0 ] connectionId=0 ]
Bill Kovar
bkovar at avaya.com <mailto:bkovar at avaya.com>
Avaya, Inc.
(732) 852-2609
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
<mailto:resiprocate-devel at list.resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.resiprocate.org
<mailto:resiprocate-devel at list.resiprocate.org>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
<https://list.resiprocate.org/mailman/listinfo/resiprocate-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070308/0bb78515/attachment.htm>
More information about the resiprocate-devel
mailing list