Subject: clarification on CSeq for putting media on hold

From: "Larry Dolinar" <[email-masked]>
Date: Tue, 2 Nov 1999 17:51:51 -0600

In the updated draft (as well as the RFC) on the SIP spec
(mmusic-sip-new-00), section B.5 talks about setting the SDP connection
address (c=) to 0.0.0.0 to request suspending media streams, but nothing
really touches on any change to CSeq: values.  In most other areas, higher
CSeq values for an existing call leg are used to indicate an update to
session parameters.  Does "update" read as "change in formats" then?
Suspension of existing ones is treated differently?  

Does this more or less force the receiver of the new INVITE to dig all the
way to the payload to find this out?  It seems at variance with the original
intent, but I'm probably misinterpreting the wording, or overlooked an
earlier post.

I mention this since I saw the messaging in
<draft-sparks-sip-service-examples-00.txt> explicitly reuse the same CSeq
value as user B puts A on hold (pg.11).  

   F13 /* User B places User A on hold. */
   INVITE
   B -> Proxy 1

          INVITE sip:[email-masked] SIP/2.0
          Via: SIP/2.0/UDP there.com:5060
          Route: <sip:[email-masked]>
          From: TheLittleGuy <sip:[email-masked]>;tag=314159
          To: TheBigGuy <sip:[email-masked]>
          Call-Id: [email-masked]
>>        CSeq: 1 INVITE
          Contact: TheLittleGuy <sip:[email-masked]>
          Content-Type: application/sdp
          Content-Length: ...

But when B picks back up, CSeq increases (pg.12).  

          /* User B takes the call off hold */

   F19
   INVITE
   B -> Proxy 1

          INVITE sip:[email-masked] SIP/2.0
          Via: SIP/2.0/UDP there.com:5060
          Route: <sip:[email-masked]>
          From: TheLittleGuy <sip:[email-masked]>;tag=314159
          To: TheBigGuy <sip:[email-masked]>;tag=1234567
          Call-Id: [email-masked]
>>          CSeq: 2 INVITE
          Contact: TheLittleGuy <sip:[email-masked]>
          Content-Type: application/sdp
          Content-Length: ...

So I'm confused...

thanks in advance,
larry

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 02 Nov 1999 20:17:54 -0500

Each new request for the same call has a new CSeq number, including a
re-INVITE to put media on hold. This is necessary to avoid confusing
different requests. This has to be media-specific, since you may want to
put video on hold, but not audio, or vice versa. Thus, this belongs into
the SDP part, not the SIP message.

> Larry Dolinar wrote:
> (mmusic-sip-new-00), section B.5 talks about setting the SDP
> connection address (c=) to 0.0.0.0 to request suspending media
> streams, but nothing really touches on any change to CSeq: values.  In
> most other areas, higher CSeq values for an existing call leg are used
> to indicate an update to session parameters.  Does "update" read as
> "change in formats" then?  Suspension of existing ones is treated
> differently?
> 
> Does this more or less force the receiver of the new INVITE to dig all
> the way to the payload to find this out?  It seems at variance with
> the original intent, but I'm probably misinterpreting the wording, or
> overlooked an earlier post.
> 
> <draft-sparks-sip-service-examples-00.txt> explicitly reuse the same
> CSeq value as user B puts A on hold (pg.11).
> 

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

---

From: Igor Slepchin <[email-masked]>
Date: Tue, 02 Nov 1999 20:31:22 -0500

> "change in formats" then?  Suspension of existing ones is treated

There is no exception here to the general rule that new request means
higher CSeq, that's why CSeq is not mentioned in B.5.
 
>           Content-Type: application/sdp

This is the first request sent from B to A, and CSeq numbering spaces in
both directions are independent. So there is no violation of the
protocol here. However, there is a CSeq-related mistake in that
scenario: the first INVITE from A to Proxy1 and the second INVITE sent
by A in response to the challenge received from Proxy A both have a CSeq
of 1 - this is wrong, CSeq should be incremented.
 
---
Igor Slepchin