[reSIProcate] Route Set problem with Update in resip 1.1 RC1
Byron Campen
bcampen at estacado.net
Thu Mar 8 10:25:04 CST 2007
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
>
> 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
>
> Avaya, Inc.
>
> (732) 852-2609
>
>
>
>
>
> From: Byron Campen [mailto:bcampen at estacado.net]
> Sent: Wednesday, March 07, 2007 4:31 PM
> To: Kovar, William (Bill)
> Cc: 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:5061;transport=tls SIP/2.0
>
>
>
> Via: SIP/2.0/UDP 135.8.116.33:5060;branch=z9hG4bK-d8754z-
> b20c1e5c1c57e971-1---d8754z-;rport
>
>
>
> 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=0945f2f40dddb181b46f94dc00
>
>
>
> From: "IC 7.1 B2B"<sip: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="MTE3MzMzMTA4NTpTREZTZXJ2ZXJT
> ZWNyZXRLZXk6NzQ1MTU0ODc4",uri="sip:
> 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 tid=03950393A79343D4439ec3.0
> cseq=UPDATE 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: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=z9hG4bK80945f2f40ddd
> b1c1b46f94dc00
>
>
>
> Max-Forwards: 69
>
>
>
> Record-Route: <sip:135.8.52.181:5060;lr>
>
>
>
> Contact: " CONFERENCE 2"<sip:76800 at avaya.com:
> 5061;transport=tls>;isfocus
>
>
>
> To: "IC 7.1 B2B" <sip:56000 at avaya.com>;tag=b855e212
>
>
>
> From: sip: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
> tid=83A503034493935543998a.0 cseq=UPDATE 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: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=z9hG4bK80945f2f40ddd
> b1c1b46f94dc00
>
>
>
> Max-Forwards: 69
>
>
>
> Record-Route: <sip:135.8.52.181:5060;lr>
>
>
>
> Contact: " CONFERENCE 2"<sip:76800 at avaya.com:
> 5061;transport=tls>;isfocus
>
>
>
> To: "IC 7.1 B2B" <sip:56000 at avaya.com>;tag=b855e212
>
>
>
> From: sip: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 tid=83A503034493935543998a.0
> cseq=UPDATE 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 tid=83A503034493935543998a.
> 0 cseq=UPDATE 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 tid=83A503034493935543998a.0
> cseq=UPDATE 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-0945f2f40dddb181b46f94dc00
> ![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: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=z9hG4bK80945f2f40ddd
> b1c1b46f94dc00
>
>
>
> Max-Forwards: 69
>
>
>
> Record-Route: <sip:135.8.52.181:5060;lr>
>
>
>
> Contact: " CONFERENCE 2"<sip:76800 at avaya.com:
> 5061;transport=tls>;isfocus
>
>
>
> To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212
>
>
>
> From: <sip: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
> tid=83A503034493935543998a.0 cseq=UPDATE 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
> tid=83A503034493935543998a.0 cseq=UPDATE 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=z9hG4bK80945f2f40ddd
> b1c1b46f94dc00
>
>
>
> Record-Route: <sip:135.8.52.181:5060;lr>
>
>
>
> Contact: <sip:56000>
>
>
>
> To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212
>
>
>
> From: <sip: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 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=z9hG4bK80945f2f40ddd
> b1c1b46f94dc00
>
>
>
> Record-Route: <sip:135.8.52.181:5060;lr>
>
>
>
> Contact: <sip:56000>
>
>
>
> To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212
>
>
>
> From: <sip: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=z9hG4bK80945f2f40ddd
> b1c1b46f94dc00
>
>
>
> Record-Route: <sip:135.8.52.181:5060;lr>
>
>
>
> Contact: <sip:56000 at 135.8.116.33:5060>
>
>
>
> To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212
>
>
>
> From: <sip: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
>
> Avaya, Inc.
>
> (732) 852-2609
>
>
>
> _______________________________________________
>
> resiprocate-devel mailing list
>
> resiprocate-devel at list.resiprocate.org
>
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
>
> _______________________________________________
>
> resiprocate-devel mailing list
>
> resiprocate-devel at list.resiprocate.org
>
> 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/74afe329/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070308/74afe329/attachment.bin>
More information about the resiprocate-devel
mailing list