Subject: [SIP] CSeq matching and multiple requests.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 12 Jun 2000 22:09:15 -0700

I have a query about the CSeq matching logic.

I don't think I have seen anything in the INFO or 2543bis drafts explicitly
forbidding having multiple outstanding requests: eg a re-INVITE and INFO
both outstanding. If this is the case then the CSeq matching logic is flawed
as you cannot rely on the value CSeq monotonically increasing.

Section 11.5 of RFC2543bis "Receiving Subsequent Requests" states that if
the Cseq doesn 't match any previous requests AND the CSeq is higher than
the last received value, then it is a new request.

This doesn't work if can you have multiple outstanding requests. For
instance, consider the case where one side sends an INFO request (eg
application/mgcp-event) and then shortly after sends a re-INVITE.
[Independent mid-call signaling is most immediate use I can see for multiple
requests]. Now consider if the first INFO request UDP message is lost but
the INVITE is not -> the INVITE can arrive before the INFO retransmission.
Using the above logic, the UAS will now never respond to the INFO request.

I remember on Henning's page, a CSeq clarification alluded to disallowing
multiple outstanding requests but my interpretation of that (after
subsequent discussion) was that this was referring to INVITE responses from
either side (ie the glare condition).

If I have missed some crucial piece of text then I think it should be moved
to a more logical place in the draft (eg Section 11). Do we need multiple
outstanding requests (per UA) anyway ? It certainly complicates matters
significantly but also has a number of benefits!!
It opens a whole can of worms: how many simultaneous requests? one per
method? how do you handle CSeq? 

Comments?

Robert.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 13 Jun 2000 23:58:19 -0400

> as you cannot rely on the value CSeq monotonically increasing.

It has been discussed, but I don't think a concrete conclusion was ever
reached on whether it was allowed.

> Using the above logic, the UAS will now never respond to the INFO request.

This is true assuming the behavior for requests that are not new is to
ignore them. If you are supporting multiple outstanding requests, you
would not ignore such requests. You could determine them to be
retransmissions if the CSeq matched a CSeq you had seen before, "old" if
the CSeq is lower than the highest received CSeq, and "new" if its
higher than the highest received CSeq. Both old and new requests would
need to be processed.

> outstanding requests (per UA) anyway ? 

It would be nice to hear if anyone has any concrete examples of a need
for this.

> It certainly complicates matters

No doubt, but nothing that isn't solvable.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 14 Jun 2000 17:08:36 +0300

Hi all,

The rcf2543bis states in section 6.45.2

"Every host that sends or forwards a SIP request adds a Via field indicating the
host’s address. However, it is possible that Network Address Translators (NATs)
change the source address and port of the request (e.g.,from a net-10 to a
globally routable address), in which case the Via header field cannot be relied
on to route replies. To prevent this, a proxy SHOULD check the top-most Via
header field to ensure that it contains the sender’s correct network address, as
seen from that proxy. If the sender’s address is incorrect, the proxy MUST add a
“received” parameter to the Via header field inserted by the previous hop. Such
a modified Via header field is known as a receiver-tagged Via header field."

So, it is possible that the port is also changed.  Yet the syntax for
via-received looks like this:

via-received = ”received” ”=” host

shouldn't  it be

via-received = ”received” ”=” hostport
or
via-received = ”received” ”=” host [":" port]

Thanks,
Hisham

---

From: Neil Deason <[email-masked]>
Date: Wed, 14 Jun 2000 15:22:56 +0100

Correct, this is noted towards the end of Appendix G - Changes To
Be Made as	"recieved-port for NAPT support in Via header field".

Cheers,
Neil
-- 
Ubiquity Software Corporation, UK          
http://www.ubiquity.net

---

From: Billy Biggs <[email-masked]>
Date: Wed, 14 Jun 2000 10:28:50 -0400

Hisham Khartabil ([email-masked]):

> via-received = "received" "=" host
> 
> shouldn't  it be
> 
> via-received = "received" "=" hostport
> or
> via-received = "received" "=" host [":" port]

  Wouldn't that be nice.  You could put it in, but it won't help the NAPT
problem.

  Unfortunately, responses in SIP always go back to the port listed in
the sent-by of the Via, NOT the source of the message.  This means you
are free to open a UDP socket just to send one message and then nuke the
socket (since the response will come back on your listening socket).

  This means that you don't care what port you received it on, you just
care what port is listed in the sent-by of the Via.  If the SIP message
went through an NAPT, then the sent-by will list the wrong port anyways,
and there won't be much use in indicating which port the message came
from.

  The solution would be to recommend that clients use the same socket
(source port) that they receive messages in as the socket they send
messages from, and therefore sending a response to the source port will
'usually' work.

  It might be worth it.....

-- 
Billy Biggs                         [email-masked]
http://www.div8.net/billy       [email-masked]

---

From: Billy Biggs <[email-masked]>
Date: Wed, 14 Jun 2000 10:39:10 -0400

> Be Made as	"recieved-port for NAPT support in Via header field".

  Cute, I hadn't noticed that.

  The spec would have to be changed to suggest that clients always send
from the port that they intend to receive the message on, where possible.
That breaks stuff pretty bad.

  I know my client (for one) opens a new socket for every outgoing
message, and then closes it after.  This is very very bad, and actually
breaks my own NAT ALG (Linux doesn't like it when you do this).  I'm
going to fix my client, and I guess it's probably a good idea if we
discourage unnecessary source port changes.

  Thoughts?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 14 Jun 2000 15:38:16 -0400

Billy Biggs wrote:
> > host?s address. However, it is possible that Network Address Translators (NATs)
> > header field to ensure that it contains the sender?s correct network address, as
> > seen from that proxy. If the sender?s address is incorrect, the proxy MUST add a
> > ?received? parameter to the Via header field inserted by the previous hop. Such

The only problem is that it does require listening to more sockets
(every sending socket), unless you use a single socket to send and
receive all messages (that socket would have to be on port 5060,
typically).

Having a single socket is difficult since it can't be a connected socket
(which you need to detect ICMP errors).

Thus, effectively, this means that you need to listen to every sending
socket. I don't think that's a big deal (thread-based applications
probably do that anyway), but it is a minor cost.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 15 Jun 2000 11:30:56 -0500 (CDT)

>It would be nice to hear if anyone has any concrete examples of a need

There are some thoughts that such a need might arise during ISUP
tunneling for some national variants of ISUP. From a practical 
point of view, you also have the issue that PRACKs are also 
being sent and completeing before the INVITE receives a final 
response.  I would strongly prefer that PRACK isn't an exception 
to an overall rule of "one pending request per direction".

The simple way to get around the problem being described is to say 
that you can't send a new request until the previous request has 
received a response. Note the subtle difference: not completed, 
just received a response (including provisionals).

This may cause problems at proxies, who can generate 100s
without the far end necessarily receiving the message. You
*could* have the proxies hold onto the messages until the next
hop responds to the previous messages to ensure in-order delivery,
but this seems overly complicated.  Perhaps, as in most other 
cases, we can just say that 100 responses are an exception?

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Jun 2000 03:14:13 -0400

> That breaks stuff pretty bad.

Exactly. This is a significant change from current behavior. I do not
think we can do it, since it is not backwards compatible.

Anyway, getting SIP through a NAT, with media and all working, is much
harder than just this, and requires an ALG anyway. So, I'm not sure
there is much gained in adding this port change. 

-Jonathan R.