Subject: [Sipping] Re: Question about Section 3.8 of draft-ietf-sipping-basic-call-flows-01.txt (Eiji Tomimura)

From: "manoj mallik" <[email-masked]>
Date: Fri, 18 Oct 2002 18:28:43 -0500

Eiji,
in the response to the CANCEL(i.e in 200-OK(CANCEL)), the To tag value
should be same as that of in 1xx response. i.e the Proxy should use the same
To tag value, which is in the provisional response, proxy already know.
Proxy should not pickup any new value.
If u will refer RFC-3261, sec:9.2 , it is mentioned that
"This response is constructed following the procedures described in Section
8.2.6
   noting that the To tag of the response to the CANCEL and the To tag
   in the response to the original request SHOULD be the same"

regards,
Manoj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, October 18, 2002 11:00 AM
To: [email-masked]
Subject: Sipping digest, Vol 1 #671 - 4 msgs

Send Sipping mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sipping
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sipping digest..."

Today's Topics:

   1. Re: Question about Section 3.8 of
       draft-ietf-sipping-basic-call-flows-01.txt (Eiji Tomimura)
   2. RE: Regarding SIP messages (Ranjit Kumar Avasarala)
   3. Comments on conferencing models (Gonzalo Camarillo)

--__--__--

Message: 1
Date: Fri, 18 Oct 2002 09:12:47 +0900
Subject: Re: [Sipping] Question about Section 3.8 of
	draft-ietf-sipping-basic-call-flows-01.txt
From: Eiji Tomimura <[email-masked]>
To: Alan Johnston <[email-masked]>, <[email-masked]>

Hi Alan,

Thank you very much for your clarification. Now, I have a further question.

As your comment, message F10 (200 OK) should have a To tag. My question is,
which value would be used for this tag.

In section 9.2 of RFC3261,
"This response is constructed following the procedures described in Section
8.2.6 noting that the To tag of the response to the CANCEL and the To tag in
the response to the original request SHOULD be the same."

In this sequence, the proxy 1 is not the sender of the response to the
original request (INVITE, F1). And also, CANCEL is referred as "hop-by-hop"
request.

But, in this case, the proxy 1 already know the To tag value in the
provisional response (180 Ringing, F8) to the F1 from the User B. And this
value should be used for the response to F1 (i.e. 487 F15).

So, my question is, can the proxy 1 pick up any value for the To tag in the
response to the CANCEL, or should the proxy use the To tag value in the
provisional response it already know.

Regards,
- Eiji Tomimura

> Eiji,
>
> Good catch - we did make the generation of 200 OKs for CANCEL the same as
> for other responses, so you are correct - message F10 should have a
> tag.  However, the CANCEL should never have a To tag, even if one has been
> received in a provisional response.  Note that  pre-RFC 3261 UAs are not
> likely to generate this tag in the response.
>
> I'll make the change in the next version.
>
> Thanks,
> Alan Johnston
> WorldCom
> sip:[email-masked]
>
> At 07:36 PM 10/17/2002 +0900, Eiji Tomimura wrote:
>> Dear all,
>>
>> I have a question in the sequence of Section 3.8 of
>> draft-ietf-sipping-basic-call-flows-01.txt.
>>
>> User A sends a CANCEL (F9) without To tag, and received 200 OK response
>> (F10) from Proxy 1. In the 200 OK, there is no To tag included, either.
>>
>> In section 9.2 of RFC3261, it says :
>> "... The UAS answers the CANCEL request itself with a 200 (OK) response.
>> This response is constructed following the procedures described in
Section
>> 8.2.6 ..."
>>
>> And in Section 8.2.6.2 says:
>> "... However, if the To header field in the request did not contain a
tag,
>> the URI in the To header field in the response MUST equal the URI in the
To
>> header field; additionally, the UAS MUST add a tag to the To header field
in
>> the response..."
>>
>> So, it seems to us that RFC3261 says that a SIP server MUST add To tag to
a
>> 200 OK response to CANCEL request, and F10 should contain To tag.
>>
>> Am I missing something? Or F10 really has a problem?
>>
>> Regards,
>> - Eiji Tomimura
>>
>> --
>> Eiji Tomimura
>> Senior Engineer
>> Systems Technology Dept., Information Technology R&D Laboratories
>> Sumitomo Electric Industries, Ltd.
>> Phone: +81-6-6466-5632  Fax: +81-6-6462-4586  Email: [email-masked]
>>
>> _______________________________________________
>> 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
>
>

--
Eiji Tomimura
Senior Engineer
Systems Technology Dept., Information Technology R&D Laboratories
Sumitomo Electric Industries, Ltd.
Phone: +81-6-6466-5632  Fax: +81-6-6462-4586  Email: [email-masked]

--__--__--

Message: 2
Reply-To: <[email-masked]>
From: "Ranjit Kumar Avasarala" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [Sipping] Regarding SIP messages
Date: Fri, 18 Oct 2002 09:29:22 +0530

Hi
   Actually S-CSCF is the SIP Server and P-CSCF is the proxy while I-CSCF
acts like Location Server.
 So say your UE is a SIP entity , then it generates INVITE message just like
any SIP entity and sends it to SIP Server i.e S-CSCF.

so you frame the sip message just like it is framed in a typical SIP stack.

Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Tuesday, October 08, 2002 2:35 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] Regarding SIP messages

hello

              I am working in developing a P-CSCF server. I have some
doubts in SIP messages. Please help me out.

1)  How can I frame a SIP message?

2) Does a SIP message have traditional header and delimeters?

3) Is  SIP message, a plain text string?

4)  Can I just create a string called invite user name @sdfds.sdfds.sdf and
with some more paramters just as a string and send it to the server or I
need to convert everything to binary and send it?

I request you to clear the above queries with an example. (Please)

Thanking You

Ganesh Iyer. S

_______________________________________________
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

--__--__--

Message: 3
Date: Fri, 18 Oct 2002 15:53:28 +0300
From: Gonzalo Camarillo <[email-masked]>
To: sipping <[email-masked]>
CC: Henning Schulzrinne <[email-masked]>,
   Jonathan Rosemberg <[email-masked]>
Subject: [Sipping] Comments on conferencing models

Hi,

Section 3.1 of the conferencing models draft:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-models-0
1.txt

still refers to appendix B of RFC 2543. It needs to be updated to say
that now there MUST always be an answer to an offer with multicast
streams.

Section 7 assumes that an end-system will return the same address/port
in the response to a previous INVITE/re-INVITE and in the response to
the current re-INVITE. That 3pcc flow (figure 7) has to be worked out
again without that assumption.

In all the 200 OK answers: (8), (11), (14), and (17), the answerer might
have changed port and address of any stream. If this happens, the
conference server will have to send an empty re-INVITE (19), (20) and so
on... to all the participants at the same time (in parallel), and wait
for all the 200 OK responses with offers before ACKing any of them. Once
the conferece server has all the information (all the offers), it will
send answers in ACKs to all the members of the conference.

This is a slightly more complex flow, but it works regardless of the
behaviour of the end-systems (which we can make a SHOULD, but not a
MUST).

Regards,

Gonzalo

--__--__--

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

End of Sipping Digest

_______________________________________________
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: Jiri Kuthan <[email-masked]>
Date: Sat, 19 Oct 2002 22:37:13 +0200

I don't think that is correct. A proxy server may relay a dozen of
provisional responses upstream, all with different to-tags
-- which of them would you like to use?

To-tags are "owned" by reply sender, they identify an E2E relationship, 
and making a proxy to use someone else's to-tags in HBH replies is IMHO 
a ticket for troubles.

So the choices for stateful proxies I see are

1) a proxy adds to-tags to its 100s (spec: MAY in 8.2.6.2, SHOULD NOT in 
   17.2.1) and uses the same to-tags for replies to CANCELs

2) it copies to-tags from CANCELs , and does not add any 
   if the CANCELs have none (which breaks the to-tag MUST requirement 
   in 8.2.6.2 and SHOULD requirement in using totag(reply(INVITE)) from 9.2)

1 is more spec-friendly, 2 is more interop-friendly.

-Jiri

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 20 Oct 2002 09:46:11 +0300

Jiri,

what Alan meant to say is that a proxy generates its *own* to tag. It
does not copy it from anywhere else.

Regarding tags in responses to CANCEL, we have to possibilities:

1) Since CANCEL is hop-by-hop, the 200 OK does not have any To tag. We
will never receive multiple 2xx responses for a CANCEL, so To tags are
not needed.

2) Instead of special casing responses to CANCEL, we treat them as any
other 2xx response. The SIP entity generating the response adds a To tag
that identifies that system -- in this case, the proxy.

If you think that a proxy answering a CANCEL is acting like a UAS for
that transaction, 2) is the way to go. If you consider that CANCEL is
such an special transaction (i.e., hop-by-hop) that needs to be special
cased, 1) is the way to go.

To make it clear, Alan proposed 2) in his mail. Personally, I do not
think this is a big deal. SIP entities generating CANCELs will have to
be prepared to receive responses with and without To tags (be liberal
with what you receive) anyway, so this will not cause interop problems.
This is more a conceptual or philosophical discussion.

Regards,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
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: Jiri Kuthan <[email-masked]>
Date: Sun, 20 Oct 2002 15:15:33 +0200

Gonzallo,

it seems that you are replying to someone else's email -- please re-read
the one I posted.

>does not copy it from anywhere else.

I don't doubt that. You might have noticed hat I had replied to 
Manoj Mallik, who proposed attaching to-tags relayed from upstream.
Which is IMHO bad.

>that identifies that system -- in this case, the proxy.

What is the difference to what I posted except 1 is swapped with 2
and vice versa?

>that transaction, 2) is the way to go. 

That was the original point -- doing so is in conflict with the
specification, which puts a SHOULD requirement on to-tags in
replies to CANCEL and INVITE to be same. We can make the spec
happy by including to-tags in 100s, but I don't see any benefit
in it (except making the spec happy). 

>If you consider that CANCEL is

That's much more closer to my preferences. Note that it breaks the
spec (see the email I wrote previously).

>This is more a conceptual or philosophical discussion.

This is a spec sanity discussion. 

-Jiri

---

From: "Bob Penfield" <[email-masked]>
Date: Sun, 20 Oct 2002 15:55:35 -0400

There seems to be some confusion here between proxy behavior and UAS
behavior. The text saying the CANCEL response's to-tag should match the
to-tag in the original request's response (section 9.2) applies to the UAS
for the original request, not a proxy.

Since the proxy does not immediately generate the 487 final response to the
original request as the UAS does (as described in section 9.2), it generates
it's own to-tag for the CANCEL response acting as the UAS for the one-hop
CANCEL request (as required by section 16.10). When the hop-by-hop CANCEL
finally reaches the UAS, the UAS puts its to-tag on both the CANCEL response
and the 487-INVITE response.

There is no need to special case the CANCEL at the proxy.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Jiri Kuthan" <[email-masked]>
To: "Gonzalo Camarillo" <[email-masked]>; "Jiri Kuthan"
<[email-masked]>
Cc: "manoj mallik" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Sunday, October 20, 2002 9:15 AM
Subject: Re: [Sipping] Re: Question about Section 3.8
ofdraft-ietf-sipping-basic-call-flows-01.txt (Eiji Tomimura)

> >> >>> Sipping mailing list

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Sun, 20 Oct 2002 21:00:14 -0500

Suppose the proxy sending the 200 for a CANCEL without a TO-tag adds one of
its own, playing by the rules of a UAS role. The UAC must ignore the To-tag
in the 200 of a CANCEL. Since there may be multiple early dialog legs
established and the CANCEL is intended for the call and not for any one leg,
the to-tag in the response is really irrelevant and should be ignored by the
UAC.
Further, the only purpose of the 200 to a CANCEL is to quench the
retransmissions of the CANCEL so there is not much point in being concerned
with the To-tag for this transaction (unless it was sent with a To-tag).

Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jiri Kuthan
Sent: Saturday, October 19, 2002 3:37 PM
To: manoj mallik; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Re: Question about Section 3.8 of
draft-ietf-sipping-basic-call-flows-01.txt (Eiji Tomimura)

-Jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 21 Oct 2002 05:37:56 +0200

Thanks for the clarification. Makes sense to me.

-Jiri

---

From: "manoj mallik" <[email-masked]>
Date: Mon, 21 Oct 2002 09:52:53 -0500

Hello Bob,
Thanks for the giving clear distinction between UAS and Proxy Behavior. This
really makes more sense and easy to understand.

Thanks,
Manoj

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Sunday, October 20, 2002 2:56 PM
To: Gonzalo Camarillo; Jiri Kuthan; Jiri Kuthan
Cc: manoj mallik; [email-masked]; [email-masked];
[email-masked]

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Oct 2002 12:29:03 -0400

Bob is correct here.

As has also been pointed out, the tag in the To field of the CANCEL is 
irrelevant. However, it is good to have consistent response generation 
rules.

-Jonathan R.

Bob Penfield wrote:
>>>>1) a proxy adds to-tags to its 100s (spec: MAY in 8.2.6.2, SHOULD NOT
>>>
> in
> 
>>>>   in 8.2.6.2 and SHOULD requirement in using totag(reply(INVITE)) from
>>>
> 9.2)
> 
>>>>>should be same as that of in 1xx response. i.e the Proxy should use
>>>>
> the same
> 
>>>>>To tag value, which is in the provisional response, proxy already
>>>>
> know.
> 
>>>>>"This response is constructed following the procedures described in
>>>>
> Section
> 
>>>>>8.2.6
>>>>>From: [email-masked] [mailto:[email-masked]]On Behalf
>>>>
> Of
> 
>>>>>[email-masked]
>>>>>Thank you very much for your clarification. Now, I have a further
>>>>
> question.
> 
>>>>>As your comment, message F10 (200 OK) should have a To tag. My
>>>>
> question is,
> 
>>>>>"This response is constructed following the procedures described in
>>>>
> Section
> 
>>>>>8.2.6 noting that the To tag of the response to the CANCEL and the To
>>>>
> tag in
> 
>>>>>original request (INVITE, F1). And also, CANCEL is referred as
>>>>
> "hop-by-hop"
> 
>>>>>request.
>>>>>
>>>>>provisional response (180 Ringing, F8) to the F1 from the User B. And
>>>>
> this
> 
>>>>>So, my question is, can the proxy 1 pick up any value for the To tag
>>>>
> in the
> 
>>>>>response to the CANCEL, or should the proxy use the To tag value in
>>>>
> the
> 
>>>>>>Good catch - we did make the generation of 200 OKs for CANCEL the
>>>>>
> same as
> 
>>>>>>tag.  However, the CANCEL should never have a To tag, even if one
>>>>>
> has been
> 
>>>>>>received in a provisional response.  Note that  pre-RFC 3261 UAs are
>>>>>
> not
> 
>>>>>>>User A sends a CANCEL (F9) without To tag, and received 200 OK
>>>>>>
> response
> 
>>>>>>>(F10) from Proxy 1. In the 200 OK, there is no To tag included,
>>>>>>
> either.
> 
>>>>>>>"... The UAS answers the CANCEL request itself with a 200 (OK)
>>>>>>
> response.
> 
>>>>>>>"... However, if the To header field in the request did not contain
>>>>>>
> a
> 
>>>>>tag,
>>>>>
>>>>>>>the URI in the To header field in the response MUST equal the URI
>>>>>>
> in the
> 
>>>>>To
>>>>>
>>>>>>>header field; additionally, the UAS MUST add a tag to the To header
>>>>>>
> field
> 
>>>>>in
>>>>>
>>>>>>>the response..."
>>>>>>>
>>>>>>>So, it seems to us that RFC3261 says that a SIP server MUST add To
>>>>>>
> tag to
> 
>>>>>a
>>>>>
>>>>>>>Phone: +81-6-6466-5632  Fax: +81-6-6462-4586  Email:
>>>>>>
> [email-masked]
> 
>>>>>Phone: +81-6-6466-5632  Fax: +81-6-6462-4586  Email:
>>>>
> [email-masked]
> 
>>>>>
>>>>>--__--__--
>>>>>
>>>>>Message: 2
>>>>>  Actually S-CSCF is the SIP Server and P-CSCF is the proxy while
>>>>
> I-CSCF
> 
>>>>>So say your UE is a SIP entity , then it generates INVITE message
>>>>
> just like
> 
>>>>>so you frame the sip message just like it is framed in a typical SIP
>>>>
> stack.
> 
>>>>>Ranjit
>>>>>
>>>>>
>>>>>
>>>>>From: [email-masked] [mailto:[email-masked]]On Behalf
>>>>
> Of
> 
>>>>>[email-masked]
>>>>>4)  Can I just create a string called invite user name
>>>>
> @sdfds.sdfds.sdf and
> 
>>>>>with some more paramters just as a string and send it to the server or
>>>>
> I
> 
>>http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-models-
> 
> 0
> 
>>>>>1.txt
>>>>>
>>>>>In all the 200 OK answers: (8), (11), (14), and (17), the answerer
>>>>
> might
> 
>>>>>conference server will have to send an empty re-INVITE (19), (20) and
>>>>
> so
> 
>>>>>for all the 200 OK responses with offers before ACKing any of them.
>>>>
> Once
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com