Subject: [Sipping] ack bug in basic call flows?

From: [email-masked]
Date: Thu, 12 Dec 2002 11:30:46 +0200

in basic call flow 3.9 Unsuccessful Busy, the invite is sent by user A
as follows:

   F1 INVITE User A -> Proxy 1 
 
   INVITE sip:[email-masked] SIP/2.0 
   Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9 
   Max-Forwards: 70 
   Route: <sip:ss1.atlanta.com;lr> 
   From: BigGuy <sip:[email-masked]>;tag=9fxced76sl 
   To: LittleGuy <sip:[email-masked]> 
   Call-ID: [email-masked] 
   CSeq: 1 INVITE 
   ...

when A receives 486 busy, it responds with ack as follows:

  F11 ACK User A -> Proxy 1 
    
   ACK sip:[email-masked] SIP/2.0 
   Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74bf9 
   Max-Forwards: 70 
   From: BigGuy <sip:[email-masked]>;tag=9fxced76sl 
   To: LittleGuy <sip:[email-masked]>;tag=314159 
   Call-ID: [email-masked] 
   CSeq: 1 ACK 
   Content-Length: 0 

the bug that i see in this is that route header is missing from the
ack.  17.1.1 says in Construction of the ACK Request:

If the INVITE request whose response is being acknowledged had Route
header fields, those header fields MUST appear in the ACK. This is to
ensure that the ACK can be routed properly through any downstream
stateless proxies.

am i missing something or is this a bug in basic call flows?

-- juha

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Thu, 12 Dec 2002 07:20:11 -0600

Hi Juha,

You are correct - this is a mistake in the flows that had been pointed out 
before - it is on my list of fixes to make.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

---

From: [email-masked]
Date: Thu, 12 Dec 2002 16:00:52 +0200

> before - it is on my list of fixes to make.

ok and while we are at it, if people have time to answer from all that
other discussion, why is lr user in initial invites like in section 3.2:

  F1 INVITE A -> Proxy 1 
    
   INVITE sip:[email-masked] SIP/2.0 
   Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74b43 
   Max-Forwards: 70 
   Route: <sip:ss1.atlanta.com;lr> 
   From: BigGuy <sip:[email-masked]>;tag=9fxced76sl 
   To: LittleGuy <sip:[email-masked]> 
   Call-ID: [email-masked] 
   CSeq: 1 INVITE 
   Contact: <sip:[email-masked];transport=tcp> 
   Content-Type: application/sdp 
   Content-Length: 143 

i would imagine that if the user has specified an outbound proxy, that
outbound proxy must be the strict next hop and should thus appear on the
invite line.

-- juha

---

From: Alan Johnston <[email-masked]>
Date: Thu, 12 Dec 2002 13:52:18 -0600

>outbound proxy must be the strict next hop and should thus appear on the

Well, it could appear on in the Request-URI as a maddr:

      sip:[email-masked];maddr=ss1.atlanta.com

but after overuse of maddr (have you ever tried to explain maddr to someone 
who does not know SIP :-) we have been trying to use other mechanisms where 
possible.  A preloaded Route header included in the INVITE seems a better 
way to express this.

As to why the Route header is a lr, I'm not certain - I suppose it could be 
strict router.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

---

From: [email-masked]
Date: Thu, 12 Dec 2002 22:15:48 +0200

> As to why the Route header is a lr, I'm not certain - I suppose it could be 

exactly this was my point.  rfc3216 text doesn't say if pre-loaded route
set which results from configuration of outbound proxy should or should
not have lr parameter in it.  

i would say that makes more sense in that case to use strict route
rather than loose route, because the outbound proxy usually has to be
the very first hop. 

in that case invite in call flow example 3.2 would look like this:

   F1 INVITE A -> Proxy 1 
    
   INVITE sip:sip:ss1.atlanta.com SIP/2.0 
   Via: SIP/2.0/TCP client.atlanta.com:5060;branch=z9hG4bK74b43 
   Max-Forwards: 70 
   Route: <sip:[email-masked]> 
   From: BigGuy <sip:[email-masked]>;tag=9fxced76sl 
   To: LittleGuy <sip:[email-masked]> 
   Call-ID: [email-masked] 
   CSeq: 1 INVITE 
   Contact: <sip:[email-masked];transport=tcp> 
   Content-Type: application/sdp 
   Content-Length: 143 

unless someone has better arguments in favor of lr usage, i suggest that
initial requests with outbound proxy are changed from lr to strict.  at
minimum the issue should be mentioned in the text, because the rfc
doesn't say anything about it and guidance would thus be needed.

-- juha

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 12 Dec 2002 14:15:13 -0800

hi,

I think preloaded routes should be loose routes. This allows them to be 
shorter (hostname only).  I think there is some specific language in 
3261 recommending a loose source route, but i don't have time to find 
it right now.

thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Dec 2002 18:26:29 -0500

Rohan Mahy wrote:
> 3261 recommending a loose source route, but i don't have time to find it 
> right now.

I agree. My impression is that for nodes that support loose routing, 
strict routing should only be used for backward compatibility.

In this particular case, it makes no practical difference to the UAC. If 
it uses a loose route, where else is it going to send it besides the 
first entry in the route? That is already its outbound proxy - where 
else could it possibly send it?

	Paul

---

From: [email-masked]
Date: Fri, 13 Dec 2002 08:25:34 +0200

> > 3261 recommending a loose source route, but i don't have time to find it 

i don't consider the length a real issue.

 > else could it possibly send it?

it may not make big difference to the ua, but it may make a big
difference if the outbound proxy is not 3216 compliant.

-- juha