Subject: [Sip] RE: Defining new requests

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 20 Feb 2004 12:40:21 +0100

Hi Gonzalo,

Thanks for your reply!

>it seems that some people in the ITU-T are having some issues 
>figuring out whether or not certain requests can be sent by the UAS within an 
>early dialog. The confusion comes from statements like this 
>one (taken from the INFO spec):
> 
> "     Unless stated otherwise, the protocol rules for the INFO request
>        governing the usage of tags, Route and Record-Route,
>        retransmission and reliability, CSeq incrementing and message
>        formatting follow those in [1] as defined for the BYE request."
> 
>Since a UAS does not send BYEs within an early dialog, but a non-2xx 
>final response instead, to terminate the dialog, people assume that INFO 
>cannot be sent in this situation either.
> 
>Let's try to keep this in mind and clarify this point when/if 
>we define new SIP methods.
> 
>In any event, the clarification to this issue can be found in 
>RFC 3398:
> 
>"From the callee to the caller, if a message is received by a gateway
>before the call has been answered (i.e., ANM is received) 
>it SHOULD be encapsulated in an INFO, provided that this will not 
>be the first SIP message sent in the backwards direction (in which 
>case it SHOULD be encapsulated in a provisional 1xx response)."

The problem is that the ITU-T interworking spec doesn't reference RFC3398. The spec reference the INFO RFC, and that is also where I think the usage rules should be defined (not in another spec, RFC3398 in this case, simply using the method).

The INFO RFC, as you said, currently says that INFO "follows the rules of BYE" (whatever that means is another question :), and the rules for BYE specifically says that it must not be sent backward before the INVITE has finished. If the INFO RFC would say "follow the rules of UPDATE" we would not have this problem, since the UPDATE spec specifically allows the use of the method before the INVITE has finished.

Thanks!

Christer Holmberg
Ericsson Finland

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Feb 2004 13:54:46 +0200

Christer,

would the ITU-T be happier if we log an errata against the INFO RFC 
saying that UASs can send INFO within early dialogs?

Gonzalo

Christer Holmberg (JO/LMF) wrote:

>>figuring out whether or not certain requests can be sent by the UAS
> 
> within an 
> 
>>final response instead, to terminate the dialog, people assume that
> 
> INFO 
> 
> The problem is that the ITU-T interworking spec doesn't reference
> RFC3398. The spec reference the INFO RFC, and that is also where I think
> the usage rules should be defined (not in another spec, RFC3398 in this
> case, simply using the method).
> 
> The INFO RFC, as you said, currently says that INFO "follows the rules
> of BYE" (whatever that means is another question :), and the rules for
> BYE specifically says that it must not be sent backward before the
> INVITE has finished. If the INFO RFC would say "follow the rules of
> UPDATE" we would not have this problem, since the UPDATE spec
> specifically allows the use of the method before the INVITE has
> finished.
> 
> Thanks!
> 
> Christer Holmberg
> Ericsson Finland

---

From: Tom Taylor <[email-masked]>
Date: Mon, 23 Feb 2004 14:08:22 -0500

The ITU-T (Study Group 11, to be exact) had a different issue with INFO: that the 
RFC depends on RFC 2543 rather than 3261.  As a result, they picked up the content 
of RFC 2976 as Annex C.3 of the ISUP interworking specification Q.1912.5.  If RFC 
2976 ever gets updated Annex C.3 can be deprecated.  In the meantime, this INFO 
question means we have some maintenance to perform.  I think the best solution 
will be to take Gonzalo's suggestion and say that INFO follows the rules for 
UPDATE.  We already have a normative dependency on the UPDATE RFC.

Gonzalo Camarillo wrote:

>>> early dialog. The confusion comes from statements like this one 
>>> (taken from the INFO spec):
>>>
>>> Let's try to keep this in mind and clarify this point when/if we 
>>> define new SIP methods.
>>>
>>> In any event, the clarification to this issue can be found in RFC 3398:
>>>
>>> before the call has been answered (i.e., ANM is received) it SHOULD 
>>> be encapsulated in an INFO, provided that this will not be the first 
>>> SIP message sent in the backwards direction (in which case it SHOULD 
>>> be encapsulated in a provisional 1xx response)."
>>
>>
>>
> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we only 
> send and receive e-mails on the basis that we are not liable for any 
> such corruption, interception, amendment, tampering or viruses or any 
> consequences thereof.
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 24 Feb 2004 09:32:52 +0200

Tom,

what is the timeframe here? As you know, we have had discussions in the 
past about either re-defining INFO so that it can only carry PSTN 
telephony signalling, or defining INFO packages. We could re-start those 
discussions, and once we reach a conclusion, clarify the rules to send 
INFO from the UAS within early dialogs in the same spec...

If the ITU is in a hurry, other solutions may be better, like logging an 
errata against the INFO RFC.

Gonzalo

Tom Taylor wrote:
> The ITU-T (Study Group 11, to be exact) had a different issue with INFO: 
> that the RFC depends on RFC 2543 rather than 3261.  As a result, they 
> picked up the content of RFC 2976 as Annex C.3 of the ISUP interworking 
> specification Q.1912.5.  If RFC 2976 ever gets updated Annex C.3 can be 
> deprecated.  In the meantime, this INFO question means we have some 
> maintenance to perform.  I think the best solution will be to take 
> Gonzalo's suggestion and say that INFO follows the rules for UPDATE.  We 
> already have a normative dependency on the UPDATE RFC.
> 
> Gonzalo Camarillo wrote:
> 
>> Christer,
>>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 25 Feb 2004 14:59:41 -0500

Q.1912.5 is in the process of final approval.  Logging errata may be satisfactory 
-- I'd have to check.  It would certainly be more comfortable than reproducing the 
RFC with modifications in the ITU document.  If the IETF acts within the next two 
weeks we should be able to remove the Annex from the Recommendation.

Here is the current list of changes as reported at the beginning of the Annex.

"The SIP INFO method is documented in RFC 2976. However, that RFC refers to RFC 
2543, the previous version of the SIP specification, rather than to RFC 3261. The 
text of this Annex reproduces RFC 2976 with changes to reflect the updated reference.

"The changes made are as follows:

"Paragraph C.3.2.1: The references to the tables of RFC2543 were changed to 
reflect the new table organization in RFC 3261.

"Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that show the 
header fields defined as presented in RFC3261. All additional headers (additional 
to RFC 2543) used within RFC3261 were here set to optional with two exceptions. 
The Reply-To (only optional for the INVITE) and Call-Info Header (only used for 
INVITE, OPTIONS, REGISTER to give additional information about the caller or 
callee) are not used with the INFO method.

"Paragraph C.3.6: The reference was changed to the current SIP specification, RFC 
3261.

Gonzalo Camarillo wrote:

>> The ITU-T (Study Group 11, to be exact) had a different issue with 
>> INFO: that the RFC depends on RFC 2543 rather than 3261.  As a result, 
>> they picked up the content of RFC 2976 as Annex C.3 of the ISUP 
>> interworking specification Q.1912.5.  If RFC 2976 ever gets updated 
>> Annex C.3 can be deprecated.  In the meantime, this INFO question 
>> means we have some maintenance to perform.  I think the best solution 
>> will be to take Gonzalo's suggestion and say that INFO follows the 
>> rules for UPDATE.  We already have a normative dependency on the 
>> UPDATE RFC.
>>
>> Gonzalo Camarillo wrote:
>>
>>> Christer,
>>>
>>>>> Since a UAS does not send BYEs within an early dialog, but a 
>>>>> non-2xx final response instead, to terminate the dialog, people 
>>>>> assume that
>>>>
>>>>
>>>>
>>>>
>>>> INFO
>>>>
>>>>> be encapsulated in an INFO, provided that this will not be the 
>>>>> first SIP message sent in the backwards direction (in which case it 
>>>>> SHOULD be encapsulated in a provisional 1xx response)."
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2004 14:26:01 +0200

Tom.

it seems that what you want is an update of the INFO spec, rather than 
fixing a few errata. I believe that we cannot meet your timeframe. In 
any event, it would be great we could start working on a solution for 
INFO in SIPPING, so that the ITU could reference it in the future.

Thanks,

Gonzalo

Tom Taylor wrote:

> Q.1912.5 is in the process of final approval.  Logging errata may be 
> satisfactory -- I'd have to check.  It would certainly be more 
> comfortable than reproducing the RFC with modifications in the ITU 
> document.  If the IETF acts within the next two weeks we should be able 
> to remove the Annex from the Recommendation.
> 
> "The SIP INFO method is documented in RFC 2976. However, that RFC refers 
> to RFC 2543, the previous version of the SIP specification, rather than 
> to RFC 3261. The text of this Annex reproduces RFC 2976 with changes to 
> reflect the updated reference.
> 
> "Paragraph C.3.2.1: The references to the tables of RFC2543 were changed 
> to reflect the new table organization in RFC 3261.
> 
> "Paragraph C.3.2: The tables 1 and 2 were replaced by new tables that 
> show the header fields defined as presented in RFC3261. All additional 
> headers (additional to RFC 2543) used within RFC3261 were here set to 
> optional with two exceptions. The Reply-To (only optional for the 
> INVITE) and Call-Info Header (only used for INVITE, OPTIONS, REGISTER to 
> give additional information about the caller or callee) are not used 
> with the INFO method.
> 
> "Paragraph C.3.6: The reference was changed to the current SIP 
> specification, RFC 3261.
> 
> 
> Gonzalo Camarillo wrote:
> 
>> Tom,
>>
>> what is the timeframe here? As you know, we have had discussions in 
>> the past about either re-defining INFO so that it can only carry PSTN 
>> telephony signalling, or defining INFO packages. We could re-start 
>> those discussions, and once we reach a conclusion, clarify the rules 
>> to send INFO from the UAS within early dialogs in the same spec...
>>
>> If the ITU is in a hurry, other solutions may be better, like logging 
>> an errata against the INFO RFC.
>>
>> Gonzalo
>>
>> Tom Taylor wrote:
>>
>>> INFO: that the RFC depends on RFC 2543 rather than 3261.  As a 
>>> result, they picked up the content of RFC 2976 as Annex C.3 of the 
>>> ISUP interworking specification Q.1912.5.  If RFC 2976 ever gets 
>>> updated Annex C.3 can be deprecated.  In the meantime, this INFO 
>>> question means we have some maintenance to perform.  I think the best 
>>> solution will be to take Gonzalo's suggestion and say that INFO 
>>> follows the rules for UPDATE.  We already have a normative dependency 
>>> on the UPDATE RFC.
>>>
>>> Gonzalo Camarillo wrote:
>>>
>>>> Christer,
>>>>
>>>>>> before the call has been answered (i.e., ANM is received) it 
>>>>>> SHOULD be encapsulated in an INFO, provided that this will not be 
>>>>>> the first SIP message sent in the backwards direction (in which 
>> interruption, unauthorized amendment, tampering and viruses, and we 
>> only send and receive e-mails on the basis that we are not liable for 
>> any such corruption, interception, amendment, tampering or viruses or 
>> any consequences thereof.
>>
>>

-- 
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

---

From: Tom Taylor <[email-masked]>
Date: Thu, 26 Feb 2004 08:00:09 -0500

As a first step, I'll submit the Q.1912.5 annex as an I-D.  I expect we'll correct 
it to use UPDATE rather than BYE as the model in Geneva in the next couple of 
weeks, so what I submit will reflect that.

Gonzalo Camarillo wrote:

>> document.  If the IETF acts within the next two weeks we should be 
>> able to remove the Annex from the Recommendation.
>>
>> "The SIP INFO method is documented in RFC 2976. However, that RFC 
>> refers to RFC 2543, the previous version of the SIP specification, 
>> rather than to RFC 3261. The text of this Annex reproduces RFC 2976 
>> with changes to reflect the updated reference.
>>
>> "Paragraph C.3.2.1: The references to the tables of RFC2543 were 
>> changed to reflect the new table organization in RFC 3261.
>>
>> INVITE) and Call-Info Header (only used for INVITE, OPTIONS, REGISTER 
>> to give additional information about the caller or callee) are not 
>> used with the INFO method.
>>
>>>> question means we have some maintenance to perform.  I think the 
>>>> best solution will be to take Gonzalo's suggestion and say that INFO 
>>>> follows the rules for UPDATE.  We already have a normative 
>>>> dependency on the UPDATE RFC.
>>>>
>>>> Gonzalo Camarillo wrote:
>>>>
>>>>> Christer,
>>>>>
>>> addressee(s). Any unauthorized review, use, disclosure or 
>>> distribution is prohibited. If you believe this message has been sent 
>>> to you in error, please notify the sender by replying to this 
>>> transmission and delete the message without disclosing it. Thank you.
>>>