Hi Matt,
Transport is modeled as client transport for sending requests/receiving responses and server transport for sending responses/receiving requests. Sending requests: **User of the transport layer** passes the client transport the request and also destination IP address, port, transport. Core obtains this destination addres/transport either through local configuration or by applying the procedures specified in RFC 3263 to Request-URI or first Route header field. Core behaving as TU communicates the destination address to transaction which is passed onto client tranport. It is also possible for the core to communicate directly with the transport layer. UAC Core sends ACK for 2xx, statless proxy communicates directly with the transport layer. Sending Responses: Via header field values in the response must equal the via header field values in the request with the same ordering. In the case of sending response, the server transport uses the value of the top via header field in the response message to determine where to send a response. 'sent-protocol' in the via header tells which protocol to use. Ramakrishna -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Gardiner Sent: Monday, November 07, 2005 7:47 PM To: '[EMAIL PROTECTED]'; [email protected] Subject: RE: [Sip-implementors] SIP over TCP Thanks Somesh, However, I think that Via is to be stamped by the stack, AFTER it has figured out what transport to use, as 8.1.1.7 of RFC3261 alludes: "A Via header field value is added only after the transport that will be used to reach the next hop has been selected" I believe that either the example I cited in rfc3665 is incorrect, or that it is not a requirement to explicitly state the transport type in the outgoing request. Matt -----Original Message----- From: Somesh S Shanbhag [mailto:[EMAIL PROTECTED] Sent: 07 November 2005 14:06 To: Matthew Gardiner; [email protected] Subject: RE: [Sip-implementors] SIP over TCP Hi Matthew, In RFC 3665 Section 3.1, transport=tcp is included in the Contact to intimate to other party that in case of any new requests within that dialog, the other party MUST use the Contact address provided and transport as TCP. I think the transport in top-most Via decides which transport to use while sending the messages. Regards, Somesh S. Shanbhag --- Matthew Gardiner <[EMAIL PROTECTED]> wrote: > Thanks Somesh, > > Yes my stack will stamp TCP or UDP into the Via > prior to transmitting the > message. I was really querying which fields in the > message inform the stack > as to which socket type (i.e. stream, datagram) to > send the message out on. > > I wonder, does your answer imply that examples such > as message F1, in > section 3.1 of RFC3665 are syntactically incorrect > as here we have an INVITE > with "transport=tcp" in the Contact: but no such > parameter in the > Request-URI? > > thanks, > Matt > > > -----Original Message----- > From: Somesh S Shanbhag [mailto:[EMAIL PROTECTED] > Sent: 07 November 2005 13:10 > To: Matthew Gardiner; > [email protected] > Subject: Re: [Sip-implementors] SIP over TCP > > > Hi Matthew, > > You have to change the Via also. Something like this > .. > > Via:SIP/2.0/TCP > 172.16.25.17:5060;branch=z9hG4bK-c7542 > > Regards, > Somesh S. Shanbhag > > --- Matthew Gardiner <[EMAIL PROTECTED]> > wrote: > > > Hi all, > > > > Could somebody please list the part(s) of a SIP > > message which must be > > changed in order to indicate to a SIP stack that > the > > message should be sent > > using TCP? > > > > I imagine these to be the Contact: header, in > order > > that the UAS knows > > whether or not to formulate a TCP or UDP packet > for > > a future request and the > > Request-URI to indicate to the transmission logic > in > > the stack that the > > destination is listening on a TCP port. If someone > > could confirm/deny my > > assumptions that would be greatly appreciated. > > > > thanks for your time, > > > > Matthew Gardiner > > Software Engineer > > Aculab > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > ----------------------------------------- > SIMPLICITY IS THE BEAUTY. > BE NATURAL LIVE NATURAL. > ----------------------------------------- > Somesh S. Shanbhag > Focus Area - VoIP Team (FA-VoIP) > Mascon Global Communication Technologies > Enterprise of Mascon Global Limited > #59/2, 100Ft Ring Road > Banashankari II stage > Bangalore-560070 > Karnataka > INDIA > Website: http://www.masconit.com > ----------------------------------------- > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > ----------------------------------------- SIMPLICITY IS THE BEAUTY. BE NATURAL LIVE NATURAL. ----------------------------------------- Somesh S. Shanbhag Focus Area - VoIP Team (FA-VoIP) Mascon Global Communication Technologies Enterprise of Mascon Global Limited #59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070 Karnataka INDIA Website: http://www.masconit.com ----------------------------------------- __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
