Resending....as i did not receive any response....

- Subhash.
----- Forwarded by Subhash Ullal Nayak/BLR/HSS on 07/02/04 04:41 PM -----
                                                                           
             [EMAIL PROTECTED]                                             
             om                                                            
             Sent by:                                                   To 
             sip-implementors-         [EMAIL PROTECTED]    
             [EMAIL PROTECTED]                                          cc 
             ia.edu                                                        
                                                                   Subject 
                                       [Sip-implementors] Confusion in     
             07/01/04 06:05 PM         Contact header                      
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








Hi implementors !
      I have a very very basic question with regard to
the Contact that should be inserted in SIP messages.
Consider [EMAIL PROTECTED] calls [EMAIL PROTECTED] Bob's phone listens
on UDP, TCP and TLS ports and receives the request on one of
these transports. Now, what is the Contact that it should
insert in the response and subsequent INVITE requests?

a) sip:[EMAIL PROTECTED]
b) sip:[EMAIL PROTECTED];transport=udp
c) sip:[EMAIL PROTECTED];transport=tcp

a) seems logical to me as it does not specify the
transport-param and therefore implies that the UA listens
on both UDP and TCP. But what if Alice made the call on TCP
and inserted a transport=tcp param in its Contact in the
INVITE request. Or what if the last hop to Bob was on TCP.
Does any of this imply that Bob should also insert transport=tcp
in the response and subsequent messages ? In general, what are
the factors that Bob's phone should consider before inserting
a Contact ?

Going through the RFC I found that it is pretty clear about
the above scenario with regard to SIPS URLs. Quoting
Sec 12.2.2: UAS Behaviour:
"The URI provided in the Contact header field MUST be a SIP
or SIPS URI.  If the request that initiated the dialog contained a
SIPS URI in the Request-URI or in the top Record-Route header field
value, if there was any, or the Contact header field if there was no
Record-Route header field, the Contact header field in the response
MUST be a SIPS URI."

Can we apply the same rules when it comes to URLs containing a
transport=xxx
parameter ?

Another question: If the URL contained transport=tls (which is
now deprecated), can the UA interpret it similar to a SIPS URL
i.e. can the UA treat it like a SIPS URL for all its processing
(i.e. apply the RFC rules as though it received a SIPS URL...)

Thanks in advance,
Subhash Nayak
Hughes Software Systems
http://www.hssworld.com
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to