On 12/31/15 4:38 PM, Dale R. Worley wrote:
"Karthik.v" <karthik...@plintron.com> writes:
1) You meant to say that Registration is creating a dialog (dialog-id) but
there is no reason for using it. Am I correct ?
A registration does *not* create a dialog, but the stream of
REGISTER messages has some of the properties of a dialog, in particular,
they share the same Call-Id.
That is usual, and recommended. But it isn't really necessary. You can
remove or refresh a registered contact using a different call-id. The
only thing that breaks in that case is temporary gruu assignment.
If the REGISTER messages *did* create a
dialog, it would not have much use, because calls cannot be sent to the
UA on it.
Yes, each call creates its own dialog.
Typically an initial INVITE will traverse the proxy/registrar. But that
proxy might not record-route. In that case it won't be present in the
dialog. That can be a good thing - it reduces load on the registrar/proxy.
Thanks,
Paul
2) No more thing is here, can u explain me the logical reason behind "The
Contact header field MUST contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog" ?
If the other UA in the dialog wants to send a request to the initial
UAC, it uses the URI from the Contact of the first request as the
request-URI. (That is because the Contact URI becomes part of the
"route set" of the dialog that is recorded by the initial UAS. The
route set is used by that UA to construct requests within the dialog.
The details are given in RFC 3261.)
Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
