Subject: [SIP] Forwarding SIP Invites -- how to decide transport.

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 27 Oct 2000 10:31:36 -0400

Greetings  (and Happy Diwali if it applies to you)  !!

I have a simple question regarding how to choose between tcp and udp
when forwarding invites. Lets say we have the following scenario:

UAC   A  registers with a proxy P using the following REGISTER:

REGISTER sip:129.6.55.9 SIP/2.0
Via: SIP/2.0/TCP 129.6.55.9:1030
Authorization: Digest username="mranga", realm="[email-masked]",
nonce="[email-masked] REGISTERThu, 26 Oct 2000 23:29:15
GMT", uri="[email-masked]",
response="9ce52922ddc7504327e6d346a45a07bb", opaque="", algorithm=MD5
From: <sip:[email-masked]>
To: <sip:[email-masked]>
Contact: <sip:[email-masked]:6060>;transport=tcp;q=0
Date: Thu, 26 Oct 2000 23:29:15 GMT
CSeq: 737064510 REGISTER
Expires: 3600
Call-ID: [email-masked]
Content-Length: 0

Later UAC B  wants to call A and sends an INVITE to the Proxy P using
the request

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/TCP 129.6.55.9:1032
Date: Thu, 26 Oct 2000 23:30:49 GMT
From: <sip:[email-masked]>
To: <sip:[email-masked]>
Subject: foobar
Priority: normal
Expires: 3600
CSeq: 598470646 INVITE
Call-ID: [email-masked]
Contact: <sip:[email-masked]>
Content-Type: application/sdp
Content-Length: 129

v=0
o=mranga 972603049 972603049 IN IP4 129.6.55.9
s=foobar
c=IN IP4 129.6.55.9
t=3181591849 3181595449
m=chat 40000 UDP 0

Now assuming that P is a stateful proxy and  it needs to forward the
invite. It knows that the protocol to use is sip because the Contact
header in the previous REGISTER from A says to use SIP. However, SIP can
be over TCP or UDP. Here's where I have the question -- how does P know
whether to use UDP or TCP  to forward the invite?  The Contact header of
the REGISTER does not specify a protocol.  Do I just use  TCP as
specified in the Via header of the REGISTER from A or do I use the
default (UDP)  protocol to forward the invote?

Thank you

Ranga.

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËbú?

---

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 27 Oct 2000 10:36:39 -0400

:Šl"
(}çZn+hžØZ¶‰ÞNŸŠ»-DAˆI1…æz·hzÉè¶Ê^r'òjÚÚ©ì¦Ší~Ší…ç(žÖœµ©ÝŠÛ!¢é]mäD„“"§]½ëž}HƒÿÛEbi"ÿm?L#õÛÞ¹çÝtß@.¶+‹6Š‰ÃŠ¬¶ë®v¦zjÚž«y©fš¶§v÷®yöz'qî|ënöóuÛÞ¹çÞ÷ïN¸ç]bLDS†íº9ËvÓM6ßouäcº¸¦©àk]½ëž}ë)¢{õÇ¹ÛÝ¶u×;çN7Û·ºw~:kŽZÓ¶Û¢–ª¹æ¥‚Šâ¶Œ‘k¢k"¦jÚžµÛÞ¹çÔè²*f©àk]½ëž}
‰íiËlŠ™«jx×ozçŸzÓ­j×“†íº9ËvÓM6ßouäc	'ªï~ôëŽuÑ!$ÄDLiŠ·¬ß4	©e >|ënöóuÛÞ¹çÐ¨ž×§´·§‚ØtN§’ÄZžŒE©àjv…©ð®‹^·ž¶)à±©ÝªiÈ8°jX¢~+Z¦™bzËhÊ‹ˆ…«ÞjÈ¦¦Wª¹ë-Š‰ëz«v)à†Œ-¡Èh¢Ç›zÜz{\¥©Ý¹Úp…éß¢¼Ø§‚)ïŠ×¬-ël±¬°z¯zØ^~‰e£§‚Çªâ¡@· ŠË^®Ì"¶©®Œr>ë"žayú%–Œ"žD„“D„“"§]½ëž}HƒÿÛEbi"ÿm?L#õÛÞ¹çÝtß@.¶+‹6Š‰ÃŠ¬¶ë®v¦zjÚž«y©fš¶§v÷®yöz'qî|ënöóuÛÞ¹çÞ÷ïN¸ç]bLDS†íº9ËvÓM6ßouäcº¸¦©àk]½ëž}ë)¢{õÇ¹ÛÝ¶u×;çN7Û·ºw~:kŽZÓ¶Û¢–ª¹æ¥‚Šâ¶Œ‘k¢k"¦jÚžµÛÞ¹çÔè²*f©àk]½ëž}
‰íiËlŠ™«jx×ozçŸzÓ­-©ì¦ŠíµÊjÐ6y8nÛ£œ·m4Ómö÷^F10’z®÷ïN¸ç]bLDDÆ˜«zÍúÓ@š–RçÎ¶ïo:×]½ëž}
‰íz{Kzx-‡BÚµêÔ pj{l¶‡–PÛÛœƒU!1-¢Ø^>º1Èû¬Šx-…êÞªç¬´ƒU!1,Š™«jx×ozçŸR ÿöÑXšHƒÿÛOÓýv÷®y÷]7Ø6y8nÛ£œ·m4Óm÷ÓF11k¢k"¦ø¤©µÛÞ¹çÔè²*f©àk]½ëž}JæãyË_¢†Ú¬úâ¢¸Êz+™©DÆ˜«zÍúÓ@’z®}óŽôëŽˆ5R&¥”€÷ã_}ëÝ¼×ozçŸB¢{ZrÛ"¦jÚžµÛÞ¹çÐ¨ž×§µ<©yªi–'¶*'þÇi
‰íz{Kzx-‡]½¿J&©àkÞöëMôãß{Û­7ÓH4ƒø×ozçŸl~Šj·4ƒø×ozçŸmß_5çÝ|ãÝõó^}çŽ=™ÈZ·4ÓE?ChÁ«,ºh§‚ØZ´ø¬jËZµçî–šèÇ&§v+gyçl¶‡è¯«vØ^Š{âµâ-’z0²ØZ¶Ø^¦º-¡Ê%¶‹¬z+,Š–Þq«¬zØ^
‰íiËay§^®)í…êkzø¨ºÄD„“ë¢`,k+-¢ëHƒÇ£¯z´ˆ=Æ§mê/z´Â>ŠÔñÞ­ë0…êÞ"¯zØ^ªç¬¶*'†Œ¡ë’z0Â…êí¢ëP3è0¶‡è¯«vØ^Š{âµäáx*'µ§-…æzº¶‘bLD]¡ë'¢Û)yÈŸÉªk¢Ú¢Pè";¬¶ëL#Ú²Ê^r'âyØ§¶•‰¨^i×«¡ûay!$ÄEúè˜
+v‚.±ëay×ŸjémP3é®‹hr‰m¡ú+ÁªÝ¶¢žú-y8ZžL¨¹§£jx«ajsHI0½©ÜyÓ^·
+’)àMç!ž‰h‚'¬º.§]4êÞjàëŠ÷’¶Š|÷mj+az»º¸m<÷ÔÞ—}5÷¾wë®kô×ŸtÓÝö±%×_6"JVg¢7ãI³jx«ajsHI0½©ÜyÓ^·
+’)àMç!ž‰h‚'¬º.§]4êÞjàëŠ÷’¶Š|÷mj+az»º¸m<÷ÔÞ—}5÷¾wë®kô×ŸtÓÝö

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 27 Oct 2000 09:51:41 -0500

> Greetings  (and Happy Diwali if it applies to you)  !!

Yes, it does.  Same to you as well :-)

> when forwarding invites. Lets say we have the following scenario:
[...]
>Oops I goofed a bit on that one. The first REGISTER  header  does  not >specify a tranansport for the contact and it should be : 
>
[...]
>Contact: <sip:[email-masked]:6060> 
[...]

Take a look at the section 1.4.2 (bis) -- it details the steps on 
locating a SIP server.  Since your example uses IP addresses directly,
P should try UDP first; if that attempt failed, it should try TCP.  Re-
call that proxies MUST support both TCP and UDP, so before failing the
call entirely, P should try both transports (and SCTP if it supports 
it).  If your example did not have IP addresses, P could have queried 
DNS for SRV records for all transports supported by it and ordered these
based on priority (see step 5 in section 1.4.2).

BTW, your earlier Contact header's syntax was in error, I think.  It was 
listed as:

It should be:

  Contact: <sip:[email-masked]:6060;transport=tcp>;q=0

Contact does not have transport parameter, addr-spec does.  Contact
only has q, action, expires and contact-extension parameters (I suppose
you could make the case that transport=tcp was a contact-extension 
parameter...)

Regards,

- vijay
-- 
Vijay K. Gurbani  [email-masked] [email-masked] [email-masked]
Internet Software Group/Intelligent Network and Messaging Systems
Lucent Technologies/Bell Labs Innovations, 263 Shuman Blvd, Rm 1A-413
Naperville, Illinois 60566  Voice: +1 630 224 0216 Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 30 Oct 2000 12:20:39 -0500

V(ÚÉ8ZžK¢¼¨ººÞ¦\“…ërØ¨Ÿ*.çÞ®Ú,k+¢¸"½éž‰ò,¢éÝ–)jV°Éêáz·…¢»(rGm«všè‚¶¦°Z+L#Ü¢yÞrÚÞ¶êç°@Ž4ÔDD„'í…ç%‰éír‹¥vz-r‰çyËm¡«®÷«jÛajÖv·¬°Z+P3í…ë(rGç²Úyº.Ûh¶zËb«b¢vv·¬²ë"ž(žwœ¶¶…êí…©ìzwm¢ŠìŠh¥j»(¶jÇœ¢wp®+^}¨¥³„@Ž4ÔDD„'í…êÞŠÉè±êïz¹b²×§Šx~Ø^rXžž×âÛ-…ë®÷«ŠÉè¶·šr›•æj–«¶'.•ªÚuÚÞ²È­Hs”,6Þ…«ÞjÈŸŠØZv·œz+Þu®4ÑÉZ²Ç«®ŠëzÊhžÇ­¢ØZ¶·ª¹ë-J‹azšèÇ(¬²êi¢Ç¶‹Õ>–œ‘ëlÂ+aiÊ'ç-jwZ±éÝjwm…éÝ¡«r‰Ý±éÝjwm…éî±äÂ>'í…å=«mzjm}¨¥°z0v‡¬ŠÙ'£ay@ÏjÛ^š›ajÇÚŠWzÊ^r&¥—,!z{axŠq©ÛÊ–¬²Ø^¦º1È‹a¢è!µ@Ïr‰çyËpjÈî²Ö©®ˆ+ji¢ž(ž÷§‰éÜzf²mâ›
èž§uÚ²z-rœ’Ú,yèŸ¶«z+rXžžÚ'¶«yÈž¾)àzwm…«pŠY`zÛazçi¥§$zÔájy,EèÛjxV(ÚÈ¡®¶§‹
èµãjx«aj|+¢×†ç­Šx,jwGjšr,–(ŸŠÖ©¦Xž²Ú2¢æ²+]¡ëjg£*.jÌ–R!j÷š²)©•ê®zËb¢zÞªÝŠx!£hr(±æÞ·žž×)jwnvœ!zwè¯«v)àŠ{âµëzÛ,k,…«Þ¶Ÿ¢YhÂ)à±Ç§j¸¨:Šl"
(}çZn+hžØZ¶‰ÞNŸŠ»-DAˆI1…æz·hzÉè¶Ê^r'òjÚÚ©ì¦Ší~Ší…ç(žÖœµ©ÝŠÛ!¢é]mäD„“"§]½ëž}HƒÿÛEbi"ÿm?L#õÛÞ¹çÝtß@¨žÖœ¶È©š¶§v÷®y÷:Ñ6¤y©h¢F¶¬yËb¢}xÙ¸¬Š×^µ¨¥²Ø^²×©²‰å¡Æ­ŠxHƒìz»Þ­(§qì¨º·±jjezë°ƒÚuÚÞ²Ç¬v*ÞrÙr>ÈhºWm¯%=ø«²ØŸ¶jÛ^š›_j)^v+l†‹¥vÚòL#ÑyÆ¥–ØZ¶šèÆ'¬1D“²êi¢»[¢ØSö§u@Ï²†Þ~ŠÞ}¨¥Šx-…ç–W§¶*Þ—#ì†‹¥vÚòn‹a¶¶§²š+¶Æ§u “>'â¶Ë©¦Ší²+H*.ìZš™^v'g¢ØZ½âi×kzË°÷(ºWaj÷ª¹êâyÐÍIú+IkyÊ+vÇè­©e¶¶§²š+¶Ë.¦š+µç[Ê+ZÚ+uêÞvØ^±æÚ±çhžšâ¢¸ÊÇž²×©æ)ìyËb¢}xØÖÊ‹«yªå‰êÂ¢{ZrØ^i×«²Ì§µ¬pjÈ§zºè¬‹aŠy·¬–+-yÖ¬
‰íiËlŠ™«jx×ozçŸzÓ­-©ì¦ŠíµÊjÐ‹l†‹¥u·‚¢{ZrÛ"¦jÚžµÛÞ¹çÞ´ëKkj{)¢»mrš´
‰íiË]¡ë'¢ØZ½ëkj{)¢»ij¶¦z×«i×k²—œv‡¬
‰íiËhž\¡jÊšrØ¨ìiŠ·¬jw\¢{Zr×±µéìŠ‰éj¶¦z×«°‹.¦š,{*.r‹¥vf¤zØ^q«¶¶¶§²š+¶×)Á«r‰íiË^Æ×§²*'¥ªÚ™ë^ j·l¾(ÚÉX£k"†º¶Úž+ä‚[œz{\¢kä‚·¬yªÜ…·¥–V›±Ê&¾Hrj+€‰íz¹Þµ*·«xjèºŸÈž×¥–(žÓ^·
+‘©Ý1ë,j§,¬µé¬.çžÔÞrè–ˆ"zÏÁzYKi»žz/jØ¨žÍºÝ(n™©Á–÷Q›P8×sZ¥êïŠY^"YbžˆëNzéZ"qïµë}6Û6×¡ZÇízßNõßM|àÄZž§jØZœÒLojwt×­ÂŠäŠxyÈg¢Z ‰ë®‹©×Mº·š¸:â½ä­¢Ÿ=ÛAšŠØ^®Æî®ÛO=õ7¥ßM}ïúëZÇ}5çÝ4÷}

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 30 Oct 2000 11:48:47 -0600

Ranga:

Please see embedded comments:

"M. Ranganathan" wrote:
> 
> Vijay,
> 
> Thanks for your reply.  The section you refer to says  (forgive me if 
> I sound like a lawyer here!) :
> 
> 
>  (For socket-based
>    programs: For TCP, connect() returns ECONNREFUSED if the client 
> could not connect to a server at that address. For UDP, the socket 
> needs to be bound to the destination address using connect() rather 
> than sendto() or similar so that a second write() fails with 
> ECONNREFUSED if there is no server listening) If the client finds the 
> server is not reachable at a particular address, it SHOULD behave as 
> if it had received a 400-class error response to that request.
> 
> 
> So the proxy is supposed to send UDP packets with a connect and a send 
> and then do a *second* send and then use TCP if the UDP attempt fails? 

Yes.  If the proxy sends a request downstream over a UDP transport, it
has to set its retransmission timer so that if if it does not get a 
response by the time the retransmission timer has run down, it will
retransmit the request.  On proxying the request the second time, it
will get a ECONNREFUSED on the connected UDP socket.  Then, it should
try TCP.

> How does it know the UDP attempt has failed (especially when the ACK 
> can bypass the proxy) ?

Um, let's see...the ACK comes much later.  Since you mention the ACK, I
presume you are talking about proxying an INVITE downstream.  Let's work
with that scenario.  A proxy gets an INVITE request from upstream UAC.
It looks into its registrations and sees that the entity being invited
to is registered (IP address is in registration database, transport is
NOT).  So, it proxies the INVITE to the downstream UAS using UDP as the
first transport choice.  When that fails (see ECONNREFUSED discussion
in the above paragraph), it tries TCP.  If TCP connect attempt succeeds, 
the request is proxied downstream.

If the downstream UAS accepts the call, it will send the proxy a 200 OK
response, which is proxied to the upstream UAC.  The ACK will be gen-
erated by the upstream UAC.  If the proxy wanted to be in future sig-
naling path, it would have included a Record-Route in the INVITE it
proxied downstream earlier.  If it did that, it'll get the ACK, since
the UAC will build the Route from the 200 OK response and the ACK will
make its way to the proxy.  If the proxy did not insert a Record-Route, 
the ACK will go directly to the UAS. 
 
> I thought UDP connect was just a programming convenience (maybe I am 
> wrong) and does not check to see if there is a client on the recieving 
> end that will get the udp packet.

You are partially right; UDP connect, unlike TCP connect, does not 
result in a 3-way handshake to ensure that the far peer indeed exists.  
All it does it to inform the kernel to record the IP address and port 
number of the peer and associate it with a socket descriptor.  Further 
I/O to a connected UDP peer can then use the convenient read()/recv() 
primitives.  Thus, it is more than a programming conbenience.  For more
information on this, consult Stevens Unix Network Programming, Volume 
1, Section 8.11 ("connect Function with UDP").

Regards,

- vijay