On 12/30/15 1:32 AM, Karthik.v wrote:
Hi all,
I have some list of queries on sip ,
It sounds like you are just getting started with sip. If you haven't
already, you would do well to read one or more of the introductory books.
1) Please state a real time scenario where multiple contact headers will be
present in a REGISTER request ?
It is certainly not a common situation. I can propose possibilities, but
they are generally far fetched.
For instance, you might send a register with multiple contacts with
expires=0 to clear them out of the registrar. Or a UA that has two
addresses might choose to register them both. (But it would be better to
record them as alternatives in DNS and register just the DNS name.)
2) Why Register does not establish a dialog & subscribe establish a dialog ?
REGISTER doesn't, but SUBSCRIBE does.
Sometimes what register does is described as a pseudo-dialog. It does
use call-id, but doesn't maintain all the same state that a dialog does.
The basic framework was set up long ago, with RFC2543 or before. At the
time the notion of dialog wasn't well developed.
SUBSCRIBE came along later, and did reuse dialog. Even then decisions
were made that were later regretted. In particular, initially a dialog
could be shared between an INVITE and some number of subscriptions. That
turned out to cause trouble, so dialog sharing was deprecated. But it is
still used in some cases.
3) As per rfc 3261, it has been said that contact header is not mandatory in
REGISTER request but without contact header in REGISTER request our app is
generating 400 Bad Request, whether it is right or wrong ?
Your app is wrong. A register without contacts is a query, to learn what
contacts have been registered.
4) Why ACK should be considered as a transaction ?
It's complicated. It is sometimes a transaction and sometimes not.
If an INVITE *fails* (response code in 3xx-6xx range) then the ACK is
part of the INVITE transaction. But when the INVITE *succeeds* (with 2xx
response) then the 2xx ends the invite transaction and the ACK is a
separate transaction.
The reason for this is that when the INVITE fails, it can only fail
once, but when it succeeds, it can succeed multiple times (due to
forking), and each one needs to be ACKed. And in that case those ACKs
sent using the contact and Route from the 2xx.
5) What's the logical reason behind the "The Contact header field MUST
contain exactly one SIP
or SIPS URI in any request that can result in the establishment of a
dialog" ?
That determines the remote contact for the resulting dialog, and is used
for sending future requests within the dialog. If there was more than
one, then it wouldn't be clear where to send. (SIP doesn't have
multipath support.)
Good luck,
Paul
Thanks & Regards,
Karthik V
_______________________________________________
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
