Holger Schmidt wrote:
> Hello,
>
> Paul Kyzivat wrote:
>
>>Also, you typically don't address the registrar. Instead you address the
>>domain of your AOR in the REGISTER. (I.e. a register for
>>sip:[EMAIL PROTECTED] is sent to sip:atlanta.com.) Often that is a proxy
>>that either also acts as a registrar, or else has local policy to route
>>REGISTER requests to a specific registrar node. So when you talk about
>>sending OPTIONS to the registrar, I guess you mean alice would send it
>>to sip:atlanta.com. That would presumably be responded to by the
>>atlanta.com "proxy" (but acting as a UA). If there is a separate
>>registrar, atlanta.com probably would not route the OPTIONS to it.
>
>
> ... RFC 3665 specifies SIP basic call flow examples. In these examples
> the registrar is addresses as "REGISTER sips:ss2.biloxi.example.com
> SIP/2.0".
>
> In this case you do not have the problem mentioned above (proxy might
> not forward message...), because the separate registrar has an own SIP-URI.
>
> Is this true?
Looking at 3665 it appears that ss2.biloxi.example.com is a combined
proxy and registrar. Also, it appears that DNSSRV translation of
biloxi.example.com points to ss2.biloxi.example.com. (Look at section
3.2 where at F5, Proxy1, processing an R-URI of
sip:[EMAIL PROTECTED], sends it to ss2.biloxi.example.com.
It is not clear in that document how it is that
client.biloxi.example.com decides to send its REGISTER to
ss2.biloxi.example.com. Certainly it is legal for it to do so, and in
this case it has the right result. But I think it would be more normal
for it to populate the R-URI of the register with
sips:[EMAIL PROTECTED], and then let the address resolution rules
result in sending it to ss2.biloxi.example.com.
Perhaps the authors of 3665 would like to comment on this.
But the basic point is that in general you probably won't know the
actual address of your registrar, or whether it is also a proxy. And you
shouldn't have to. Send the OPTIONS request to the logical address you
care about.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
