[reSIProcate] Route Set problem with Update in resip 1.1 RC1
Robert Sparks
rjsparks at nostrum.com
Wed Mar 7 16:34:54 CST 2007
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="MTE3MzMzMTA4NTpTREZTZXJ2Z
>>>> XJTZWNyZXRLZXk6NzQ1MTU0ODc4",uri="sip:
>>>> 76800 at avaya.com",response="e1bdfe0882c087d5334812ad288f7c60",algori
>>>> thm=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: UPDATE
>>>> 56000 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=z9hG4bK80945f2f40
>>>> dddb1c1b46f94dc00
>>>>
>>>> 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: UPDATE 56000 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=z9hG4bK80945f2f40
>>>> dddb1c1b46f94dc00
>>>>
>>>> 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: 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> 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: 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> 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=z9hG4bK80945f2f40
>>>> dddb1c1b46f94dc00
>>>>
>>>> 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: 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> DEBUG | Helper.cxx:372
>>>> | Helper::makeResponse(SipReq: UPDATE 56000 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=z9hG4bK80945f2f40
>>>> dddb1c1b46f94dc00
>>>>
>>>> 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=z9hG4bK80945f2f40
>>>> dddb1c1b46f94dc00
>>>>
>>>> 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=z9hG4bK80945f2f40
>>>> dddb1c1b46f94dc00
>>>>
>>>> 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/20070307/3c6e2ab0/attachment.htm>
More information about the resiprocate-devel
mailing list