Hi Vishal, The rule for that is, if you decide to send a request on TCP and it fails because of socket failure (Which will happen if the receiver is not listening on UDP) the same message, with Via header modified with UDP, has to be sent over UDP. This is a fall back mechanism. It works only from TCP to UDP and not the other way.
There are some more rules: 1. Responses will always go over the same transport as request. No fall back will apply here. 2. If an ACK message is part of the INVITE transaction, it will go over the same transport as the original INVITE. No fall back will apply here. 3. Stateless proxies should use the same transport for the outgoing message as that of the received message. For all other cases, selection of the transport for outgoing message is independent of the received message. The transport selection process itself has several laws, depending on message type (Request, response, request part of a transaction), message length, DNS reply for the URL, presence of transport= field in the Route URL or the Request URI. They are explained in detail in RFC 3261 Section 18 and RFC 3263. Biplab. Vishal Mathur wrote: > Hi Alex, > > I am not sure that approach of send sip messages our TCP is correct if the > original transport was UDP. This is because sender might not be having any > connection open on TCP at all. That means sender has only connection open for > UDP transport. > > I think SIP RFC allow use to implement SIP stack only on UDP or TCP or even > both. So if the implementation is only with UDP the above approach will fail. > > Have any body tried sending reply to TCP port for Cisco ATA or IP phone when > original message was generated on UDP? > Does it work? > > Regards, > > Vishal Mathur > Jabber ID: [EMAIL PROTECTED] > Symantec Corporation > www.symantec.com > _________________________________ > Office: +91-20-66067655 > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ? ?? > Sent: Thursday, November 15, 2007 2:15 PM > To: [EMAIL PROTECTED]; [email protected] > Subject: Re: [Sip-implementors] How to determine transport to use from > Routeheader > > Hi all. > In addition to below, if the total size of sip message is over a MTU in > constructing, you have to change the transport to TCP even though the > original transport was UDP. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 라스토기 > Sent: Thursday, November 15, 2007 10:33 AM > To: [email protected] > Subject: Re: [Sip-implementors] How to determine transport to use from Route > header > > Hi, > if route has sip then it is UDP, if sips then TLS and sip with transport as > TCp then TCP. > I hope it helps... > Vipul Rastogi > Engineer, Business Management Team > Telecommunication Network Business > Samsung Electronics CO, LTD > Suwon P.O.BOX 105, 416 > Korea 442-600 > MO 010-9530-0354 > > Hi, > > > > Can anyone please tell me How to find out the transport protocol to send > the request, when we have to use the > > > > Route header for determining next hop. > > > > Suppose we have a Route header with the value > > > > Route: <sip:10.58.2.21:5060;lr>, <sip:10.48.2.40:5061;lr> > > > > Now because the first route value contains the lr parameter so the IP > and Port of the next hop will be 10.58.2.21 and 5060 respectively, But > > > > How to find out the transport to be used in this case. > > > > Regards, > > Jitendra. > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
