Barman, Sibon B (Sibon) wrote:
> When a user agent sends a REGISTER request with private address in the
> Contact header, the session border element sends a response with the
> UA's public IP address in the contact header as well as in the Via
> header's rport and received parameters. Is that correct spec-wise ---
> should the UA be able to handle this registration response and treat it
> as its own contact? Or does the 3261 spec dictate that the response
> should contain the same contact address as the request?
This sounds bogus to me. But a registrar has a lot of lattitude. It is
probably not technically illegal, but is behavior that should be
expected to present problems for standard conforming UAs.
The response to the REGISTER should contain the contacts that are in
fact registered. If the contact was being registered with a non-zero
expiration time, and was successful, then you would expect to see that
same contact in the response. In principle the registrar is free to
ignore the contact, or accept it but decide to expire it immediately, so
that it doesn't show up in the response. But that would be bizarre.
I think what you are implying is that an SBC is replacing the contact
address in the REGISTER with another address and then passing the
request on to the registrar. And when the response is returned, the SBC
is *not* doing the inverse translation on contact in the response.
Since there are no rules for SBCs, I guess we can't say for certain that
the SBC is wrong to do this. But if it is attempting to be "transparent"
so that a "normal" UA will work with it, then it is not doing a very
good job.
If the UA is expected to cope with this situation, *how* is it expected
to do so? It must look at the response to discover the actual expiration
time of its registration. If its own contact isn't there, how can it
recognize which one applies to it and hence what the expiration time is?
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
