Subject: [Sipping] ISUP Overlap Signaling : Will keeping the To: header unchanged work better

From: [email-masked]
Date: Tue, 15 Oct 2002 10:41:10 -0500

Hi,

The draft "Mapping of ISUP Overlap Signalling to the Session Initiation
Protocol" suggests that the subsequent INVITE messages for overlap
signaling have a new To: header and new Request-URI but same From header
and From tag.
This causes the egress gateway to send multiple IAM messages.

I was wondering if we could rather state that only the Request-URI should
be modified for overlap signaling. This way we could use the target refresh
to minimize the number of IAMs sent on the egress side. Also a smart egress
gateway could use this re-INVITEs with same Callid, From, From tag, To to
generate a SAM.

Any comments on this would be appreciated.

Thanks,

Anoop Tripathi
3COM

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 16 Oct 2002 08:20:32 +0300

Hi,

You will get several IAMs only if your INVITEs hit different egress
gateways. If they hit the same gateway, you will get an IAM for the
first INVITE and SAMs for the rest.

About changing the To, you have to ensure that all the INVITEs have a
complete To header field, because it may happen that an egress gateway
only sees the last INVITE you sent. Having an incomplete To header field
might confuse that gateway.

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: Eiji Tomimura <[email-masked]>
Date: Thu, 17 Oct 2002 19:36:31 +0900

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]

---

From: Alan Johnston <[email-masked]>
Date: Thu, 17 Oct 2002 09:47:32 -0500

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]

---

From: Eiji Tomimura <[email-masked]>
Date: Fri, 18 Oct 2002 09:12:47 +0900

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

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 19 Oct 2002 21:35:53 +0200

At 04:47 PM 10/17/2002, Alan Johnston wrote:
>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.  

I think "never" is too bold. The original INVITE might have had a to-tag in it
("re-INVITE"), and its CANCEL should follow it. It's a corner case, though --
I'd be surprised to see some reasonable use of re-invite cancellation.

>Note that  pre-RFC 3261 UAs are not likely to generate this tag in the response.
>

With reference to the next Eiji's email, I'd prefer not to do it.
I'll post on it shortly.

-jiri