oh, duh. The Linksys device is the victim here, not the culprit.
Paul
Paul Kyzivat wrote:
>
> Stephan Steiner wrote:
>> Actually this proxy/registrar (the Linksys SPA9000), does things in a rather
>> interesting way:
>
> Well... you will note that my email address is @cisco.com, and Linksys
> is part of Cisco, but I disclaim any knowledge or responsibility for
> what Linksys products do.
>
> More below...
>
>> Here's how the UA registers:
>>
>> REGISTER sip:192.168.1.4:6060 SIP/2.0
>> Via: SIP/2.0/UDP 192.168.1.143:1027;branch=z9hG4bK-15jt0sfyr8xy;rport
>> From: "Stephan Snom" <sip:[EMAIL PROTECTED]:6060>;tag=hw631v8q8o
>> To: "Stephan Snom" <sip:[EMAIL PROTECTED]:6060>
>> Call-ID: 3c26701a4f62-4xco7y4yu87v
>> CSeq: 2 REGISTER
>> Max-Forwards: 70
>> Contact:
>> <sip:[EMAIL
>> PROTECTED]:1027;line=hz1fyz3p>;flow-id=1;q=1.0;+sip.instance="<urn:uuid:6269fe47-3672-4acd-8027-baa939f7a89f>";audio;mobility="fixed";duplex="full";description="snom370";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO"
>> User-Agent: snom370/7.1.6
>> Supported: gruu
>> Allow-Events: dialog
>> X-Real-IP: 192.168.1.143
>> WWW-Contact: <http://192.168.1.143:80>
>> WWW-Contact: <https://192.168.1.143:443>
>> Expires: 600
>> Content-Length: 0
>>
>> And here's the INVITE that the device gets:
>>
>> INVITE sip:[EMAIL PROTECTED]:6060 SIP/2.0
>> Via: SIP/2.0/UDP 192.168.1.4:6060;branch=z9hG4bK-1b7ff369__0
>> Via: SIP/2.0/UDP 192.168.1.107:5060;branch=z9hG4bK-1b7ff369
>> From: "Stephan" <sip:[EMAIL PROTECTED]:6060>;tag=53b9f14b44e6731o0
>> To: "Stephan Snom" <sip:[EMAIL PROTECTED]:6060>
>> Remote-Party-ID: "Stephan"
>> <sip:[EMAIL PROTECTED]:6060>;screen=yes;party=calling
>> Call-ID: [EMAIL PROTECTED]
>> CSeq: 101 INVITE
>> Max-Forwards: 70
>> Contact: "Stephan"
>> <sip:[EMAIL
>> PROTECTED]:5060>;+sip.instance="<00000000-0000-0000-0000-000E08DCD09E>"
>> Expires: 240
>> User-Agent: Linksys/SPA942-5.1.10
>> Content-Length: 395
>> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE
>> Allow-Events: dialog
>> Supported: replaces
>> Content-Type: application/sdp
>>
>> As you can see, the Request URI in the INVITE is actually addressed to the
>> proxy, and not the UA.
>
> Perhaps it is attempting some sort of NAT traversal technique.
>
>> This is how the request URI should look for the UA
>> initiating the call - but the proxy doesn't seem to change it for calls
>> between UAs that are in the same network. As soon as the call leaves my
>> network, I see the Request URI replaced though.. it then becomes
>> [EMAIL PROTECTED]
>>
>> It's interesting that the way you describe the "broken proxy" flag is
>> exactly the explanation that Snom's wiki has for that option. I've never had
>> this kind of issue with this proxy before so I suppose all the other UAs
>> I've tried (quite a handful) aren't very strict at Request URI matching
>> either.
>
> I'm no expert, but I do have the impression that lots of UAs don't care
> what is in the R-URI as long as it arrives at the correct address and port.
>
>> Is there no explicit mention that a proxy should replace the request URI
>> with the contact that the registrar stored upon registration?
>
> Of course there is.
>
>> It's hard
>> enough convincing the manufacturer when the RFC is crystal clear on the
>> subject :/
>
> I don't have a line to Linksys. But if you want to contact me offline
> about this maybe we can figure out something.
>
> Thanks,
> Paul
>
>> Regards
>> Stephan
>>
>> ----- Original Message -----
>> From: "Paul Kyzivat" <[EMAIL PROTECTED]>
>> To: "Jeroen van Bemmel" <[EMAIL PROTECTED]>
>> Cc: "Stephan Steiner" <[EMAIL PROTECTED]>;
>> <sip-implementors@lists.cs.columbia.edu>
>> Sent: Friday, July 20, 2007 11:58 PM
>> Subject: Re: [Sip-implementors] relationship between contact URI in REGISTER
>> andrequest uri in INVITE
>>
>>
>>> I largely agree with Jeroen.
>>>
>>> The UA is the master of its own address. It tells others the address(es)
>>> where it is willing and able to receive requests. REGISTER is one way it
>>> can tell others (the registrar) its address(es).
>>>
>>> This is much like postal addresses. A postal address might be:
>>> Alice Smith
>>> 123 Main Street
>>> Atlanta, GA
>>>
>>> If a letter is sent to
>>> Bob Jones
>>> 123 Main Street
>>> Atlanta, GA
>>>
>>> then Alice may see it, but is likely not to process it as incoming mail to
>>> her. She might throw it away, or might read it but not process it
>>> normally.
>>>
>>> In the case of SIP, there are many reasons that the UA may want to encode
>>> information of interest to itself in the contact address, in the user part
>>> or in URI parameters. And it may then expect and need that information
>>> returned to it when the registrar forwards calls to it. (See the GRUU spec
>>> for important reasons to preserve the URI.)
>>>
>>> The 3261 procedures for registrars will preserve the contact URI as it was
>>> registered. Doing otherwise isn't following 3261.
>>>
>>> The "broken proxy flag" is akin to telling Alice that she should process
>>> all mail delivered to her mailbox as if it was her own mail. (E.g. If it
>>> is a bill addressed to Bob she should go ahead and pay it. :-)
>>>
>>> What kind of changes are you seeing in the contact? Is the user part being
>>> lost? Is the domain name being replaced by an IP address? Or what? (None
>>> of these is a valid change, but I'm interested to understand what is going
>>> on.)
>>>
>>> Paul
>>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
