Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.txt

From: [email-masked]
Date: Thu, 13 Oct 2011 05:19:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-08.txt
	Pages           : 30
	Date            : 2011-10-13

   This memo describes use cases, requirements, and protocol extensions
   for using the Session Description Protocol (SDP) Offer/Answer model
   for establishing audio and video media streams over circuit-switched
   bearers in the Public Switched Telephone Network (PSTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.txt

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 12:21:09 +0000

Hello all,

We just submitted a new version of draft-ietf-mmusic-sdp-cs.

Changes in the -08 version include:

Added a new section "Offer/Answer extensions" detailing the process of handling the O/A exchange. 

Clarified that multiple extensions for cs-correlation are allowed.

Added a request for IANA to create a sub-registry for "cs-correlation" attribute values, with "Specification Required" policy. 

Clarified how dynamic payloads are handled. Basically we stick to normal SDP processing here, i.e. if dynamic payload types are used, a=rtpmap attribute(s) are required. This may need more thought still.

Changed a lot of SHOULDs into MUSTs.

Extended the example in Section 6.

Flemming had a comment on mandating E.164 numbers in the international format. After some thinking, we still say that the enpoints SHOULD include the number in international format. The network may anyway mangle the number presentation, so we thought mandating the intl format is not absolutely necessary.

TODO: Security considerations needs more work based on Flemming's earlier comments (including caller's E164 number in SDP).
TODO: Clarification on the mechanism works with 3PCC.
TODO:Change the UUIE syntax to allow for a discriminator byte.

We hope to address the remaning issues still before the IETF submission deadline.

Regards,
Simo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 13 October, 2011 15:19
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-08.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-08.txt
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Oct 2011 14:46:34 -0400

I reviewed draft-ietf-mmusic-sdp-cs-08 and have a number of comments:

5.2.1

This says addresses for the E164 address type are represented according 
to ITU-T E.164. If I have followed the reference correctly, it only 
specifies the country codes, not the encoding of numbers including 
country codes. I think it would be better to define this by reference to 
RFC 3966 (TEL) and to either telephone-subscriber, or global-number, or 
global-number-digits defined there. (I'm not sure which of those is most 
appropriate for your use.)

Also, you give the example

     c=PSTN - -

That requires that "-" be a defined address type. AFAIK it is not.
Did you mean it to be

     c=PSTN E164 -

5.2.3.1

The syntax given for a=cs-correlation is inconsistent with the syntax in 
5.6 and with usage throughout the document.

5.2.3.3

You specify that the UUIE has a max size of 35 or 131 octets. AFAIK the 
actual max information content is actually either 32 or 128 octets plus 
a leading protocol discriminator byte.

Its unclear what you intend to be included in the specified uuie element 
in the sdp - does it include the protocol discriminator or not?

Also, the content and protocol discriminator contain octets, not just 
alphanumerics, but the syntax in 5.6 only permits alphanumerics. Is it 
your *intent* to limit the protocol discriminator and the value to that 
subset described by alphanumerics? And is that a reasonable thing to do? 
(For this use, it *might* be sufficient to prescribe a specific value 
for the protocol discriminator.)

5.5.1 / 5.5.4

The description of a=connection here is more appropriate to section 
5.5.4. Here, for the initial offer, a=connection:new is the only thing 
that makes sense.

In 5.5.4 it would be helpful to explain in more detail how a=connection 
is used to control whether an existing call is retained, dropped, or 
dropped and reestablished.

(In some cases it will be desired to do another o/a while leaving the 
pstn call undisturbed. In other cases it may the explicit intent to 
cause the call to be reestablished.)

5.6

Is there a reason why you don't use the definition of an E.164 number 
from RFC 3966, rather than using your own? What is the significance of 
making the "+" optional? And why is caller-id-value defined differently 
than e164-address?

Figure 4, and others:

The E.164 number used (+15551234) isn't a valid one for country code 1.

General Comment:

Everything is described, and examples show, only a single m= line, and 
all the cs-correlation and setup things used within that one media 
section. There is no explanation of what to do if there is more than one 
pstn m= line, as might arise if the intent is to have an audio/video 
call. Without any explanation, it would seem that everything should be 
specified separately for each m= line, which might result in *two* pstn 
calls. Presumably that isn't want is desired.

More definition is needed if the same pstn call is to be used for two 
media streams.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 15 Oct 2011 14:52:49 +0200

Paul wrote

> appropriate for your use.)

E.164 defines the country codes in an annex. The main body of the recommendation defines the structure of a number consisting of country code and national significant number for international number. And national and subscriber prefix and appropriate part of the number for national number and subscriber number usage. The definition also includes various length limitations, and identifies local service numbers.

However I suspect that the reference here needs to explicitly limit it to international numbers defined by E.164.

I see no need to go via RFC 3966 which becomes only significant in terms of referencing if you want to define local numbers.

Regards

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 14 October 2011 19:47
> To: [email-masked]
> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-08.txt
> 
> > Added a request for IANA to create a sub-registry for "cs-correlation"
> attribute values, with "Specification Required" policy.
> >
> > Clarified how dynamic payloads are handled. Basically we stick to normal
> SDP processing here, i.e. if dynamic payload types are used, a=rtpmap
> attribute(s) are required. This may need more thought still.
> >
> > Flemming had a comment on mandating E.164 numbers in the international
> format. After some thinking, we still say that the enpoints SHOULD include
> the number in international format. The network may anyway mangle the
> number presentation, so we thought mandating the intl format is not
> absolutely necessary.
> >
> > TODO: Security considerations needs more work based on Flemming's
> earlier comments (including caller's E164 number in SDP).
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Multiparty Multimedia
> Session Control Working Group of the IETF.
> >
> > 	Title           : Session Description Protocol (SDP) Extension For
> Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In
> The Public Switched Telephone Network (PSTN)

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 16 Oct 2011 10:25:12 +0200

Hi Keith.

I am a bit confused with your comment indicated that the reference should 
be limited to international numbers defined by E.164. I think E.164 is 
all about international numbers. As a matter of fact, the title of E.164 
is "The international public telecommunication numbering plan", and the 
scope clearly indicates that it is about international numbers.

However, I think we need to elaborate a bit more the '+' sign, which is 
not part of the E.164 specification, but a common trick to represent a 
full international E.164 number.

/Miguel

On 15/10/2011 14:52, DRAGE, (Keith) wrote:
> Paul wrote
>
>> 5.2.1
>>
>> This says addresses for the E164 address type are represented
>> according to ITU-T E.164. If I have followed the reference
>> correctly, it only specifies the country codes, not the encoding of
>> numbers including country codes. I think it would be better to
>> define this by reference to RFC 3966 (TEL) and to either
>> telephone-subscriber, or global-number, or global-number-digits
>> defined there. (I'm not sure which of those is most appropriate for
>> your use.)
>>
>
> E.164 defines the country codes in an annex. The main body of the
> recommendation defines the structure of a number consisting of country
> code and national significant number for international number. And
> national and subscriber prefix and appropriate part of the number for
> national number and subscriber number usage. The definition also
> includes various length limitations, and identifies local service
> numbers.
>
> However I suspect that the reference here needs to explicitly limit it
> to international numbers defined by E.164.
>
> I see no need to go via RFC 3966 which becomes only significant in
> terms of referencing if you want to define local numbers.
>
> Regards
>
> Keith
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat Sent: 14
>> October 2011 19:47 To: [email-masked] Subject: Re: [MMUSIC] FW: I-D
>> Action: draft-ietf-mmusic-sdp-cs-08.txt
>>
>> This says addresses for the E164 address type are represented
>> according to ITU-T E.164. If I have followed the reference
>> correctly, it only specifies the country codes, not the encoding of
>> numbers including country codes. I think it would be better to
>> define this by reference to RFC 3966 (TEL) and to either
>> telephone-subscriber, or global-number, or global-number-digits
>> defined there. (I'm not sure which of those is most appropriate for
>> your use.)
>>
>> The syntax given for a=cs-correlation is inconsistent with the
>> syntax in 5.6 and with usage throughout the document.
>>
>> 5.2.3.3
>>
>> You specify that the UUIE has a max size of 35 or 131 octets. AFAIK
>> the actual max information content is actually either 32 or 128
>> octets plus a leading protocol discriminator byte.
>>
>> Its unclear what you intend to be included in the specified uuie
>> element in the sdp - does it include the protocol discriminator or
>> not?
>>
>> Also, the content and protocol discriminator contain octets, not
>> just alphanumerics, but the syntax in 5.6 only permits
>> alphanumerics. Is it your *intent* to limit the protocol
>> discriminator and the value to that subset described by
>> alphanumerics? And is that a reasonable thing to do? (For this use,
>> it *might* be sufficient to prescribe a specific value for the
>> protocol discriminator.)
>>
>> 5.5.1 / 5.5.4
>>
>> 5.5.4. Here, for the initial offer, a=connection:new is the only
>> thing that makes sense.
>>
>> In 5.5.4 it would be helpful to explain in more detail how
>> a=connection is used to control whether an existing call is
>> retained, dropped, or dropped and reestablished.
>>
>> (In some cases it will be desired to do another o/a while leaving
>> the pstn call undisturbed. In other cases it may the explicit intent
>> to cause the call to be reestablished.)
>>
>> 5.6
>>
>> Is there a reason why you don't use the definition of an E.164
>> number from RFC 3966, rather than using your own? What is the
>> significance of making the "+" optional? And why is caller-id-value
>> defined differently than e164-address?
>>
>> Figure 4, and others:
>>
>> Everything is described, and examples show, only a single m= line,
>> and all the cs-correlation and setup things used within that one
>> media section. There is no explanation of what to do if there is
>> more than one pstn m= line, as might arise if the intent is to have
>> an audio/video call. Without any explanation, it would seem that
>> everything should be specified separately for each m= line, which
>> might result in *two* pstn calls. Presumably that isn't want is
>> desired.
>>
>> More definition is needed if the same pstn call is to be used for
>> two media streams.
>>
>> Thanks, Paul
>>
>>> Added a new section "Offer/Answer extensions" detailing the
>>> process of
>> handling the O/A exchange.
>>>
>> SDP processing here, i.e. if dynamic payload types are used,
>> a=rtpmap attribute(s) are required. This may need more thought
>> still.
>>>
>> format. After some thinking, we still say that the enpoints SHOULD
>> include the number in international format. The network may anyway
>> mangle the number presentation, so we thought mandating the intl
>> format is not absolutely necessary.
>>>
>>> TODO: Clarification on the mechanism works with 3PCC. TODO:Change
>>> the UUIE syntax to allow for a discriminator byte.
>>>
>>> We hope to address the remaning issues still before the IETF
>>> submission
>> deadline.
>>>
>>> Regards, Simo
>>>
>>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] On Behalf
>> Of ext [email-masked]
>>> Sent: 13 October, 2011 15:19 To: [email-masked] Cc:
>>> [email-masked] Subject: [MMUSIC] I-D Action:
>>> draft-ietf-mmusic-sdp-cs-08.txt
>>>
>> Setting Up Audio and Video Media Streams Over Circuit-Switched
>> Bearers In The Public Switched Telephone Network (PSTN)
>>> Author(s)       : Miguel A. Garcia-Martin Simo Veikkolainen
>>> Filename        : draft-ietf-mmusic-sdp-cs-08.txt Pages
>>> : 30 Date            : 2011-10-13
>>>
>>> This memo describes use cases, requirements, and protocol
>>> extensions for using the Session Description Protocol (SDP)
>>> Offer/Answer model for establishing audio and video media streams
>>> over circuit-switched bearers in the Public Switched Telephone
>>> Network (PSTN).
>>>
>>>
>>> mmusic mailing list [email-masked]
>>> _______________________________________________ mmusic mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________ mmusic mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 16 Oct 2011 12:16:15 +0200

Hi Paul.

You can find my comments inline, except for one that we are discussing 
with Keith in a separate e-mail.

> That requires that "-" be a defined address type. AFAIK it is not.

No, we meant:

     c=PSTN - -

The idea is frequently a device will know that is Circuit-Switched 
capable, but it wouldn't know its own E.164 number, or even it is 
allocated an E.164 number. It could be possible that the device is aware 
of a different numbering plan (for example, E.212).

So, in summary: we want to express that the device has a PSTN 
Circuit-Switched connection, but it is not aware of its address in any 
numbering plan.

In Section 8.3, we register with IANA both the E.164 and the dash "-" tokens.

> 5.6 and with usage throughout the document.

I am comparing Sections 5.2.3.1 and 5.6, and the usage throughout the 
document and I don't find this inconsistency. Can you elaborate a bit 
more what this inconsistency is?

> a leading protocol discriminator byte.

Right. The terminology in Q.931 helps to mislead. The User-User 
Information Element contains three parts:

- 1-octet User-user information element identifier
- 1-octet "Length of user-user contents"
- 1-octet "Protocol discriminator"
- "User Information".

The "User Information can be up to 32 or 128 octets, depending on 
networks. Together with the other 3 octets, it makes a maximum of 35 or 
131 octets.

I guess the draft should elaborate the composition of this information 
element and clarify that it includes the 3 initial octets.

> in the sdp - does it include the protocol discriminator or not?

Yes, as I described above.

> for the protocol discriminator.)

This is an error that we should fix. It is not the intention of this 
draft to limit the protocol discriminator, so, we need to address this 
issue and allow any possible value. We will fix it in the next version of 
the draft.

Ok, we can move the a=connection:existing to 5.5.4.

> cause the call to be reestablished.)

ok, will do.

> from RFC 3966, rather than using your own?

RFC 3966 defines how to represent an E.164 number as a URL. Here, we do 
not intent to use URLs. Additionally, the tel: URL provide representation 
of either global and local numbers, ISDN subaddresses, extensions, and 
phone context, which are not intended to be used here.

 > What is the significance of
> making the "+" optional?

The only reason I can think, is that the draft has a "SHOULD" strength 
for using the international format of E.164. If someone really knows what 
he is doing and can use a national format, it wouldn't use the "+" sign. 
I recognize that this is not a very strong reason, but it is the only 
justification I can find.

 > And why is caller-id-value defined differently
> than e164-address?

Yes, I think they should be equal. Probably we should get rid of 
"caller-id-value" and use "e164-address" instead.

> The E.164 number used (+15551234) isn't a valid one for country code 1.

Is it because there are not enough number of digits for the subscriber 
number?

> More definition is needed if the same pstn call is to be used for two

Yes, I agree with you. I think we should add a section describing how to 
setup an circuit-switched audio/video call.

> 	Paul

Thanks for your comments,

        Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 16 Oct 2011 23:42:48 +0200

I think the issue is that you are variously using all sorts of terminology. I see in the document:

	E.164 number
	in E.164 format
	E.164 address

Your main definition is:

   For the address type, we initially consider the possibility of
   describing E.164 telephone numbers.  We define a new "E164" address
   type.  When used, the "E164" address type indicates that the
   connection address contains a telephone number represented according
   to the ITU-T E.164 [ITU.E164.1991] recommendation.

Even if the prime purpose of E.164 is to define international numbers there are multiple types of number defined in E.164, e.g. 

	4.10	global subscriber number (GSN)
	4.18	national (significant) number [N(S)N]
	4.24	subscriber number (SN)

The definition you are looking for is:

4.16	international public telecommunication number
	F:	numéro de télécommunications publiques internationales
	S:	número de telecomunicaciones públicas internacionales
A string of decimal digits that, for a geographic country code, uniquely identifies a subscriber or a point where a service is provided. For the case of a global service code, it identifies the subscriber of the service. For Networks, it identifies a subscriber of the Network.
An international public telecommunication number (hereafter referred to as "international E.164 numbers") can act in the "role" of both a name and an address. Portability is reducing a number's role as an address. Numbers are increasingly acting in the role of a name only.
The number, which includes the country code and subsequent digits, but not the international prefix, contains the information necessary to route the call to this termination point on a public network (it may also contain the supplementary information necessary to forward it on a private network). It is sometimes referred to as an "E.164 number" or "international number".

So my view is that your main definition can be construed as referring to any of the numbers defined in E.164 which I have listed. The term "telephone number" refers to both national and international numbers. 

For the remainder of the document, while E.164 number is permissible as an indication of your required term, I think you would be better using one of the preferred terms either "international E.164 numbers" or "international public telecommunication number". Whichever you use, use it consistently throughout the document.

If you are specifically indicating the address type, I suggest you consistently put the E.164 in quotation marks, followed by the words "address type" in full.

The "+" is actually part of ITU-T Recommendation E.123: "Notation for national and international telephone numbers, e-mail addresses and Web addresses". However you cannot use E.123 as a blanket reference as it also includes space characters and parentheses, unless you wish these to also be valid.

Regards

Keith

> From: Miguel A. Garcia [mailto:[email-masked]]
> Sent: 16 October 2011 09:25
> To: DRAGE, Keith (Keith)
> Cc: Paul Kyzivat; [email-masked]

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 17 Oct 2011 08:55:58 +0200

Very good comments Keith, thanks.

We will have to do a pass throughout the document trying to make it 
consistent. I think we should be using the term "international E.164 
number". And I believe we shouldn't make a reference to E.123, but 
explain the usage of the plus sign.

BR,

    Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Oct 2011 18:27:30 -0400

Miguel - comments inline.

	Thanks,
	Paul

> In Section 8.3, we register with IANA both the E.164 and the dash "-"

OK, I see its registered. And I found it mentioned in passing.
But I don't find a specification for what the connection-address 
may/must be when the addrtype is "-".

In 4566 there is:

    When the <addrtype> is IP4 and IP6, the connection address is defined
    as follows:

    o  ...

It would be helpful if this doc had a similar thing:

    When the <addrtype> is PSTN, the connection address is defined
    as follows:

    o  an e164-address

    When the <addrtype> is "-", the connection address is defined
    as follows:

    o  the value "-", signifying that the address is unknown.
OR
    o  any syntactically valid value, which is to be ignored..

> more what this inconsistency is?

5.2.3.1 has:

    a=cs-correlation: callerid:<callerid-value> |
                      uuie:<uuie-value>           |
                      dtmf:<dtmf-value>           |
                      *[extension-name:<extension-value>]

This requires callerid, uuid, and dtmf to be mutually exclusive, rather 
than permitting one of each as 5.6 allows. Also, the ":" and value are 
required rather than being optional.

> element and clarify that it includes the 3 initial octets.

Based on the examples, and some common sense, I think you don't want to 
specify the first two of the above in the SDP. AFAIK the first has a 
well defined value, and the second is well defined by counting the bytes 
in the uuie-value.

> issue and allow any possible value. We will fix it in the next version
> of the draft.
>
>
>
>>
>> 5.5.1 / 5.5.4
>>
> not intent to use URLs. Additionally, the tel: URL provide
> representation of either global and local numbers, ISDN subaddresses,
> extensions, and phone context, which are not intended to be used here.

I meant not the entire tel syntax, but by reference to one of the ABNF 
symbols defined in 3966. That has the benefit of being more accessible 
to those reading ietf drafts, and to give the syntax in ABNF that can be 
readily incorporated with the rest of the syntax.

Of course that would allowing visual-separator. I don't know if that is 
a big deal or not.

> for using the international format of E.164. If someone really knows
> what he is doing and can use a national format, it wouldn't use the "+"
> sign. I recognize that this is not a very strong reason, but it is the
> only justification I can find.

Well, if the intent is to allow a national format, then it should be 
made clear that lack of the "+" means that. (And then how on how one is 
supposed to know *which* national format.)

I realize there is text that says the actual callerid received may not 
be in E.164 format and so the comparison should take that into account. 
But I didn't think that applied to the number specified in SDP.

> Is it because there are not enough number of digits for the subscriber

Right. Its just a nit. There is no area code in it.

>>> Added a request for IANA to create a sub-registry for
>>> "cs-correlation" attribute values, with "Specification Required" policy.
>>>
>>> Clarified how dynamic payloads are handled. Basically we stick to
>>> normal SDP processing here, i.e. if dynamic payload types are used,
>>> a=rtpmap attribute(s) are required. This may need more thought still.
>>>
>>> Flemming had a comment on mandating E.164 numbers in the
>>> international format. After some thinking, we still say that the
>>> enpoints SHOULD include the number in international format. The
>>> network may anyway mangle the number presentation, so we thought
>>> mandating the intl format is not absolutely necessary.
>>>
>>> submission deadline.
>>> Title : Session Description Protocol (SDP) Extension For Setting Up
>>> Audio and Video Media Streams Over Circuit-Switched Bearers In The
>>> Public Switched Telephone Network (PSTN)

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 Oct 2011 22:03:30 +0200

Hi Paul, see inline comments.

On 18/10/2011 0:27, Paul Kyzivat wrote:
>      When the<addrtype>  is IP4 and IP6, the connection address is defined
>      as follows:
>
>      o  ...
>
>      When the<addrtype>  is PSTN, the connection address is defined
>      as follows:
>
>      o  an e164-address
>
>      When the<addrtype>  is "-", the connection address is defined
>      as follows:
>

Good point. We will add it to the draft.

> required rather than being optional.

Aha, I see it know. The correct one is in 5.6, so we will change 5.2.3.1.

> well defined value, and the second is well defined by counting the bytes

It is true that the fist octet is fixed and the second is the length, so 
they do not really convey useful information. But we do really need the 
third octet (the protocol discriminator). Based on this, I would prefer 
to include the whole object (User-user information element) rather than 
the object minus two octets.

> Of course that would allowing visual-separator. I don't know if that is

Actually, this field should only contain digits.

> But I didn't think that applied to the number specified in SDP.

That is correct. That does not apply to the number included in SDP, but 
to the received Caller-ID in Q.931. Some operators of some countries send 
this number in international format; others send it in national format.

Unless someone has a very good reason, I guess we can preclude national 
numbers from SDP, so we should remove the '+' sign from the syntax.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 12:39:34 -0400

On 10/18/11 4:03 PM, Miguel A. Garcia wrote:

trimming out the settled stuff

> the object minus two octets.

Really??? I find that just an invitation to confusion and error.

Also, you should take a look at what is being done in the CUSS wg - 
draft-ietf-cuss-sip-uui-02.

For this purpose you have some latitude in what you allow. It isn't 
really necessary to allow all data bytes, all lengths, or all protocol 
discriminators. You only need to allow enough to work in all networks 
and to provide sufficient randomness. The cuss work wants to provide 
access to the complete mechanism, and even beyond that when not going 
over a PSTN link. So you might choose different approach. But its at 
least worth a look.

(Personally, I haven't been happy with CUSS including the protocol 
discriminator in the string with the data, but I haven't convinced 
anyone else of that.)

> Actually, this field should only contain digits.

My point in calling out 3966 is that it is more familiar to the sip 
community. But this isn't a big deal as long as the reference is specific.

> to the received Caller-ID in Q.931. Some operators of some countries
> send this number in international format; others send it in national
> format.
>

Or always include it. I guess if its always there it is redundant, but 
having it there would still remind people of what it is.

	Thanks,
	Paul