Subject: [cuss] Open Issue: Encoding format

From: Alan Johnston <[email-masked]>
Date: Mon, 7 Feb 2011 09:26:13 -0600

I think there is an issue around encoding format.  For interworking
with the ISDN, there are two potential encodings: the one used in ISDN
and the one used to encapsulate the ISDN in the SIP header field.

Which doe we need to convey?  Just the SIP one, or both?  Do we need
to define IA5 transport?

- Alan -

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Feb 2011 17:09:25 -0500

> Which doe we need to convey?  Just the SIP one, or both?  Do we need

Well, this is an interesting mess!

I'm not myself a user of this stuff. But its my impression that in many 
cases the users of this info are indeed passing *text*, and at best find 
it inconvenient to have to encode/decode it to hex.

This is independent of whether the stuff is passing through ISDN or not.

I don't know if the ISDN formats are well defined wrt whether they are 
encoded in IA5 or something else.

If they are, then conversion between a sip encoding and an ISDN encoding 
could be done by the GW.

If they are not, then its more problematic.

I've suggested before that instead of defining isdn-interwork as a 
single purpose, that there be a separate purpose defined for each valid 
value of the discriminator byte in the ISDN UUI data. If that were done, 
then it would be much more reasonable to expect a GW to convert between 
sip encodings and ISDN encodings.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 15:36:35 +0100

Hi Alan,
If you are using the ISDN encoding then you have more complex interworking procedures with SS7.
You have then to put together the encoding which is the Protocol discriminator within DSS1 and the UUI information itself.

So I would support the encapsulation of the ISDN header. This would fit for direct SIP-DSS1 and SIP - SS7 interworking.

I don't see the need for defining a IA5 transport format. A pure hex encoding, I think, is sufficient.

Or have I overseen something?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Alan Johnston
> Gesendet: Montag, 7. Februar 2011 16:26
> An: [email-masked]
> Betreff: [cuss] Open Issue: Encoding format
>
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 15:54:10 +0100

> sip encodings and ISDN encodings.

Hi Paul,
I try to understand where you are coming from.

looking in Q.931 I see the following protocol discriminator values:

0 0 0 0 0 0 0 0         User-specific protocol (Note 1)
0 0 0 0 0 0 0 1         OSI high layer protocols
0 0 0 0 0 0 1 0         Recommendation X.244 [44] (Note 2)
0 0 0 0 0 0 1 1         Reserved for system management convergence function
0 0 0 0 0 1 0 0         IA5 characters (Note 4)
0 0 0 0 0 1 0 1         X.208 and X.209 coded user information (Note 5)
0 0 0 0 0 1 1 1         Recommendation V.120 [9] rate adaption
0 0 0 0 1 0 0 0         Q.931/I.451 user-network call control messages

0 0 0 1 0 0 0 0         Reserved for other network layer or layer 3 protocols, including Recommendation
        through                 X.25 [5] (Note 3)
0 0 1 1 1 1 1 1

0 1 0 0 0 0 0 0
        through                 National use
0 1 0 0 1 1 1 1

0 1 0 1 0 0 0 0         Reserved for other network layer or layer 3 protocols, including Recommendation
        through                 X.25 (Note 3)
1 1 1 1 1 1 1 0

So this is the indication how the User Information is coded itself.

So my question is, what is then understand as a SIP encoding?

Regards

Roland

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 8 Feb 2011 16:43:57 +0100

The ISDN coding could be IA5 or binary, as determined possibly by the protocol discriminator. Moreover in the ISDN, the protocol discriminator could just be a lie. Noone checks it from one end to the other, and it has no impact on the way the network provides the service.

So as far as interworking with the ISDN is concerned, I believe it is best to treat it as always binary.

In any case, I do not believe it is appropriate at the interworking gateways to start delving into the protocol discriminator values to work out the best coding mapping.

Therefore I believe the best coding mapping for the ISDN application is always map to a binary coding within the header field. What that tranfer coding is could be optimised so one size fits all as we discussed previously on the list.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 08 February 2011 14:54
> To: [email-masked]; [email-masked]
> Subject: Re: [cuss] Open Issue: Encoding format
> 
> 
> >
> > single purpose, that there be a separate purpose defined for each 
> > valid value of the discriminator byte in the ISDN UUI data. If that 
> > were done, then it would be much more reasonable to expect a GW to 
> > convert between sip encodings and ISDN encodings.
> 
> Hi Paul,
> 0 0 0 1 0 0 0 0         Reserved for other network layer or 
> layer 3 protocols, including Recommendation
> 0 1 0 1 0 0 0 0         Reserved for other network layer or 
> layer 3 protocols, including Recommendation
>         through                 X.25 (Note 3)
> 1 1 1 1 1 1 1 0
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2011 09:25:04 -0500

>          through                 X.25 [5] (Note 3)

Roland,

My thought is that *each* of the above be defined as a distinct purpose 
value for sip uui. Then the corresponding value carried in sip would 
encode all the bytes *except* the discriminator byte (which would be 
encoded as the purpose).

An ISDN GW would then take the sip uui encoding of the value plus the 
purpose code and construct a corresponding Q.931 encoding.

The mapping from the sip encoding of the value to the Q.931 encoding 
could be defined on a per-purpose basis. But more likely the mappings 
would be common but validation could be specific.

In sip we could then have, e.g., UTF8 and hex encodings. When going from 
sip to Q.931, the hex encoding would be straightforward, but might need 
to be checked that the values were consistent with the protocol 
discriminator. When going from Q.931 to sip, the encoding could be 
chosen based on both the discriminator/purpose value and the actual content.

Even if nothing useful is defined about many of the discriminator 
values, separating them from the rest of the value has the benefit that 
when the value is representable as text in sip, but the discriminator is 
not, we would not be forced to encode the entire thing in hex.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2011 09:35:31 -0500

I just replied to Roland on this. But I'll say a little more:

One way to handle the conversion from Q.931 to sip would be "if it can 
be represented as a sip quoted string, without escapes, then represent 
it that way, else represent it as hex." And the converse conversion 
could be "convert a sip quoted string to Q.931 byte for byte, and 
convert hex to Q.931 in the obvious way, two hex characters per byte."

It could be done this way on the entire Q.931 value, including the 
discriminator byte. But that might be less than satisfactory if the 
actual data is text, but the chosen discriminator is not a nice quoted 
string value. If the discriminator is separated out, as the purpose 
value, then it won't muck up an all-text value.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 9 Feb 2011 07:48:33 -0700

I agree completely with Keith. Gateways have no business delving into the UUI or the protocol discriminator. This will only create mistakes and errors. 

My opinion is that for ISDN interworking, the encoding is the transfer encoding chosen by the Gateway with the ISDN encoding being assumed to be binary. 

 - Alan -

On Feb 9, 2011, at 7:35 AM, Paul Kyzivat <[email-masked]> wrote:

> One way to handle the conversion from Q.931 to sip would be "if it can be represented as a sip quoted string, without escapes, then represent it that way, else represent it as hex." And the converse conversion could be "convert a sip quoted string to Q.931 byte for byte, and convert hex to Q.931 in the obvious way, two hex characters per byte."
> 
> It could be done this way on the entire Q.931 value, including the discriminator byte. But that might be less than satisfactory if the actual data is text, but the chosen discriminator is not a nice quoted string value. If the discriminator is separated out, as the purpose value, then it won't muck up an all-text value.
> 
>    Thanks,
>    Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2011 10:49:32 -0500

> I agree completely with Keith. Gateways have no business delving into the UUI or the protocol discriminator. This will only create mistakes and errors.

It will lead to mistakes or errors if there is discretion or lack of 
clarity regarding the mapping. As long as the mapping is well defined, 
all should be fine.

Perhaps I am mistaken, but it certainly appears to me that the 
descriminator byte in the Q.931 format serves much the same purpose that 
the "purpose" parameter is intended to serve in the proposed sip uui 
header. It seems very natural to me that we make this correlation.

I guess the counter-argument to that is *if* the prevailing use of UUI 
in ISDN entirely ignores the intent of the discriminator byte, and 
simply uses the entire string, including the discriminator byte, as a 
single data value. I don't know if that might be the case, or not. (I 
hope not, since it is a gross abuse of the Q.931 spec.)

> My opinion is that for ISDN interworking, the encoding is the transfer encoding chosen by the Gateway with the ISDN encoding being assumed to be binary.

I have some feedback from developers that they do not appreciate being 
forced to convert text data to/from hex for this purpose. It certainly 
it won't be well appreciated by those looking at call traces. While its 
perhaps unavoidable when the actual data is binary, it is avoidable when 
the data is itself text.

	Thanks,
	Paul

>   - Alan -
>
>
>
> On Feb 9, 2011, at 7:35 AM, Paul Kyzivat<[email-masked]>  wrote:
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 10 Feb 2011 00:46:04 +0100

Essentially we have two levels of capability identification defined because the ISDN protocol discriminator is not apparently flexible enough to do this in a non-ISDN environment. 

The point I was making earlier is that the protocol discriminator in the ISDN is and end to end label. The ISDN transports something that is binary. The network is not responsible for determining whether it is as described by the protocol discriminator. So the only entities responsible for the usefulness, or not, are the two end users. As I regard any gateways between the SIP environment and the ISDN as being part of the network, be that enterprise or public, I don't see why that should end up having any determination based on the protocol discriminator value. ISDN will always have to be assumed to be binary.

I do have an impression however that much of the use is IA5. I would not from my perspective have a problem if we encoded the binary as for example % escaped characters or some similar encoding. I suspect this would be compact for the majority of ISDN users. But I am not a user of such information, I work for a company that needs to transport it.

Regards

Keith 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 09 February 2011 15:50
> To: Alan Johnston
> Cc: DRAGE, Keith (Keith); [email-masked]; [email-masked]
> > I agree completely with Keith. Gateways have no business 
> delving into the UUI or the protocol discriminator. This will 
> only create mistakes and errors.
> 
> It will lead to mistakes or errors if there is discretion or 
> lack of clarity regarding the mapping. As long as the mapping 
> is well defined, all should be fine.
> 
> Perhaps I am mistaken, but it certainly appears to me that 
> the descriminator byte in the Q.931 format serves much the 
> same purpose that the "purpose" parameter is intended to 
> serve in the proposed sip uui header. It seems very natural 
> to me that we make this correlation.
> 
> I guess the counter-argument to that is *if* the prevailing 
> use of UUI in ISDN entirely ignores the intent of the 
> discriminator byte, and simply uses the entire string, 
> including the discriminator byte, as a single data value. I 
> don't know if that might be the case, or not. (I hope not, 
> since it is a gross abuse of the Q.931 spec.)
> 
> > My opinion is that for ISDN interworking, the encoding is 
> the transfer encoding chosen by the Gateway with the ISDN 
> encoding being assumed to be binary.
> 
> I have some feedback from developers that they do not 
> appreciate being forced to convert text data to/from hex for 
> this purpose. It certainly it won't be well appreciated by 
> those looking at call traces. While its perhaps unavoidable 
> when the actual data is binary, it is avoidable when the data 
> is itself text.
> 
> 	Thanks,
> 	Paul
> 
> >   - Alan -
> >
> >
> >
> >> One way to handle the conversion from Q.931 to sip would 
> be "if it can be represented as a sip quoted string, without 
> escapes, then represent it that way, else represent it as 
> hex." And the converse conversion could be "convert a sip 
> quoted string to Q.931 byte for byte, and convert hex to 
> Q.931 in the obvious way, two hex characters per byte."
> >>
> >> It could be done this way on the entire Q.931 value, 
> including the discriminator byte. But that might be less than 
> satisfactory if the actual data is text, but the chosen 
> discriminator is not a nice quoted string value. If the 
> discriminator is separated out, as the purpose value, then it 
> won't muck up an all-text value.
> >>
> >>     Thanks,
> >>     Paul
> >>
> >>> The ISDN coding could be IA5 or binary, as determined 
> possibly by the protocol discriminator. Moreover in the ISDN, 
> the protocol discriminator could just be a lie. Noone checks 
> it from one end to the other, and it has no impact on the way 
> the network provides the service.
> >>>
> >>> So as far as interworking with the ISDN is concerned, I 
> believe it is best to treat it as always binary.
> >>>
> >>> In any case, I do not believe it is appropriate at the 
> interworking gateways to start delving into the protocol 
> discriminator values to work out the best coding mapping.
> >>>
> >>> Therefore I believe the best coding mapping for the ISDN 
> application is always map to a binary coding within the 
> header field. What that tranfer coding is could be optimised 
> so one size fits all as we discussed previously on the list.
> >>>
> >>> Regards
> >>>
> >>> Keith
> >>>
> >>>>> valid value of the discriminator byte in the ISDN UUI data. If 
> >>>>> that were done, then it would be much more reasonable 
> to expect a 
> >>>>> GW to convert between sip encodings and ISDN encodings.
> >>>>
> >>>> Hi Paul,

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2011 22:05:34 -0500

First, I just realized that I had "purpose=" and "content=" mixed up in 
my mind. (And I may still not fully understand the distinction in 
detail.) Where I have been suggesting multiple purpose values, I think I 
should have been recommending different "content=" values.

> I do have an impression however that much of the use is IA5. I would not from my perspective have a problem if we encoded the binary as for example % escaped characters or some similar encoding. I…

That may work out in many cases, but for seriously binary data it could 
be quite unpleasant.

For the ease of those that wish to restrict themselves to text and don't 
want to deal with the hex encoding, it would be good if the conversion 
from Q.931 to sip used the quoted string encoding when that didn't 
require any escaping, and otherwise use hex.

(While it would be possible to define some middle ground, I think it 
would likely just be annoying.)

But the discriminator byte then might well force many usages to hex.

I still fail to understand how having separate purposes that map onto 
specific discriminator values would cause any problem in mapping to/from 
Q.931.

Fundamentally this comes down to how *sip* users of this will perceive 
it. It doesn't matter at all for Q.931 users, since they will see what 
they have always seen. And if you have a Q.931-aware *application* that 
has been ported to sip, *something* will still have to convert between 
the sip representation and the Q.931 format the application expects, 
just as a GW will have to do.

As a SIP user, I think I would prefer to say:

User-to-User: 
"name=foo,age=33";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5

than:

User-to-User: 
046E616D653D666F6F2C6167653D3333;encoding=hex;purpose=isdn-interwork;content=isdn

or even:

User-to-User: 
"\04name=foo,age=33";encoding=text;purpose=isdn-interwork;content=isdn-uui

At the other extreme, I would also prefer to have

User-to-User: 
0000006500000020;encoding=hex;purpose=isdn-interwork;content=isdn-ia5

than:

User-to-User: "\00\00\00A\00\00\00 
";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5

or:

User-to-User: "\04\00\00\00A\00\00\00 
";encoding=text;purpose=isdn-interwork;content=isdn-uui

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Feb 2011 09:50:43 +0100

I think we would be going down a rat hole if we required any sort of conversion at ISDN gateways. End-to-end transparent transport would seem to match best the intended purpose of the ISDN service and its use in practice.

If we want a separate text format for use between SIP UAs when ISDN is not involved, that might make sense. However, an ISDN gateway would not pass this on, so one would need to avoid using this format if expecting to interoperate with ISDN.

If we do perform any conversion at ISDN gateways, we must at least ensure it is symmetrical, in the sense of what is received from ISDN at UA A gets sent in exactly the same form to ISDN at UA B. Performing no conversion is the simplest way of achieving this.

John

> Behalf Of Paul Kyzivat
> Sent: 10 February 2011 03:06
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]
> > Essentially we have two levels of capability identification 
> defined because the ISDN protocol discriminator is not 
> apparently flexible enough to do this in a non-ISDN environment.
> >
> > The point I was making earlier is that the protocol 
> discriminator in the ISDN is and end to end label. The ISDN 
> transports something that is binary. The network is not 
> responsible for determining whether it is as described by the 
> protocol discriminator. So the only entities responsible for 
> the usefulness, or not, are the two end users. As I regard 
> any gateways between the SIP environment and the ISDN as 
> being part of the network, be that enterprise or public, I 
> don't see why that should end up having any determination 
> based on the protocol discriminator value. ISDN will always 
> have to be assumed to be binary.
> >
> > I do have an impression however that much of the use is 
> IA5. I would not from my perspective have a problem if we 
> encoded the binary as for example % escaped characters or 
> some similar encoding. I suspect this would be compact for 
> the majority of ISDN users. But I am not a user of such 
> information, I work for a company that needs to transport it.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Feb 2011 11:33:37 -0500

> I think we would be going down a rat hole if we required any sort of conversion at ISDN gateways. End-to-end transparent transport would seem to match best the intended purpose of the ISDN service…

The proposed hex format *already* requires a conversion by ISDN 
gateways. Arguably, a quoted string representation would require *less* 
effort by a gateway, as long as the chars are converted 1:1.

The "advantage" of hex, if its the *only* encoding, is that it is done 
identically for every character. But its not especially friendly for 
applications or for reading message dumps.

> If we want a separate text format for use between SIP UAs when ISDN is not involved, that might make sense. However, an ISDN gateway would not pass this on, so one would need to avoid using this fo…

Yes, we could say that hex is the *only* format when the content is 
isdn-uui. Then the question is: when would anything else ever be used? 
I'm having trouble envisioning a path to use of any content other than 
isdn-uui or a purpose other than isdn-interwork.

That is part of my difficulty in discriminating between content and 
purpose. AFAIK the purpose of UUI is *never* "isdn-interwork". It is 
something like: "pass info from IVR to call center". Accomplishing that 
may or may not require isdn-interworking. That depends on the equipment 
deployed, and the IVR sending the UUI might not know.

> If we do perform any conversion at ISDN gateways, we must at least ensure it is symmetrical, in the sense of what is received from ISDN at UA A gets sent in exactly the same form to ISDN at UA B. P…

I don't think it needs to be symmetrical. There should be a single well 
defined sip representation for each ISDN uui value. A GW should always 
produce that value when converting from ISDN to sip. And a GW should of 
course also accept that representation and convert it consistently when 
going from SIP to ISDN. But there could be alternative sip 
representations that the GW is also capable of converting to ISDN.

For instance, we could go with quoted strings as the sip representation. 
In that case, the preferred representation would be to convert each ISDN 
byte to corresponding quoted character when that is allowed, and to use 
\nn only when necessary. But converting the other way would presumably 
permit other characters to be represented using the \nn form.

<flame>

I am about to give up on this. I don't care *that much*. I was hoping to 
get something that seems reasonable as a native sip facility, that also 
happens to interwork with ISDN. It seems we are on a path that results 
in all the limitations and ugliness of the Q.931 mechanism with another 
piled on layer of ugliness and inconvenience to wedge it into SIP. 
Apparently everybody else thinks that is fine.

</flame>

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 11 Feb 2011 14:47:29 +0100

Paul,

> Apparently everybody else thinks that is fine.

Do I understand you correct that you would like also to see something like that:

 User-to-User:
 "name=foo,age=33";encoding=text;purpose=sip;content
 =sip-uui-ia5

So this would make the SIP UUI interworkable.
And in parallel we would have also the ISDN-UUI as an hex coded string which can then be passed between ISDN applications. Where we are looking on.

I don't know what people are thinking on that.

Best Regards

Roland

> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Donnerstag, 10. Februar 2011 17:34
> An: Elwell, John
> Cc: DRAGE, Keith (Keith); Jesske, Roland; [email-masked]
> Betreff: Re: [cuss] Open Issue: Encoding format
>
>
>
> > I think we would be going down a rat hole if we required
> any sort of conversion at ISDN gateways. End-to-end
> transparent transport would seem to match best the intended
> purpose of the ISDN service and its use in practice.
>
> > If we want a separate text format for use between SIP UAs
> when ISDN is not involved, that might make sense. However, an
> ISDN gateway would not pass this on, so one would need to
> avoid using this format if expecting to interoperate with ISDN.
>
> > If we do perform any conversion at ISDN gateways, we must
> at least ensure it is symmetrical, in the sense of what is
> received from ISDN at UA A gets sent in exactly the same form
> to ISDN at UA B. Performing no conversion is the simplest way
> of achieving this.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Feb 2011 09:15:08 -0500

> And in parallel we would have also the ISDN-UUI as an hex coded string which can then be passed between ISDN applications. Where we are looking on.

I don't really understand the purpose parameter, and when you would use 
two different values in the same message. If you had purpose=sip and it 
goes to an ISDN GW, is it ignored? If it has a purpose *other* than 
isdn-interwork and it arrives at a UA other than an ISDN GW, is it ignored?

It seems unreasonable to expect the sending application to know whether 
the message will be going to an ISDN GW in order to decide what to put 
into the UUI header.

ISTM that the header should be useful in a natural way between two sip 
devices, and that if they suitably constrain their usage it should also 
work between two sip devices that are separated by an ISDN hop, or 
between one sip device and one ISDN device. That says to me that if only 
purpose=isdn-interwork makes it through an ISDN GW, then that is what 
any application that *might* interwork with ISDN will use, regardless of 
whether there is an actual use of ISDN.

It seems unreasonable to me that a device that wants to use UUI would 
encode its UUI information one way for ISDN and a different way for 
sip-sip communication, in the same message.

*Perhaps* it might do so in the same sense as multipart/alternative - 
where the multiple encodings are of the "same" information but with 
differing fidelity. E.g. a short form that fits the constraints of ISDN, 
and a longer form that that does not. In that case a recipient would use 
the "best" form it is capable of using. But the it wouldn't be a matter 
of text vs. hex.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Feb 2011 17:13:40 +0100

> It seems unreasonable to expect the sending application to
> know whether the message will be going to an ISDN GW in order
> to decide what to put into the UUI header.
>

But that is the essence of what we have already agreed. Go to my isdn draft and see the list of constraints. On things like restrictions on length, etc we have already agreed that the sender has to know the ISDN limits and not exceed them, otherwise all the UUI will be lost.

That expectation is expressed in different words: The sender purposefully restricts themselves to the limitations of the ISDN application in order that if interworking occurs with the ISDN, the interworking with the UUI can also occur. That restriction is identified by signalling the use of the ISDN application.

Regards

Keith

> Sent: 11 February 2011 14:15
> To: [email-masked]
> Cc: [email-masked]; DRAGE, Keith (Keith);
> [email-masked]; [email-masked]
> Subject: Re: AW: [cuss] Open Issue: Encoding format
>
>
>
> >> I am about to give up on this. I don't care *that much*. I
> was hoping
> >> to get something that seems reasonable as a native sip
> facility, that
> >> also happens to interwork with ISDN. It seems we are on a
> path that
> >> results in all the limitations and ugliness of the Q.931 mechanism
> >> with another piled on layer of ugliness and inconvenience
> to wedge it
> >> into SIP.
> > And in parallel we would have also the ISDN-UUI as an hex
> coded string which can then be passed between ISDN
> applications. Where we are looking on.
>
> I don't really understand the purpose parameter, and when you
> would use two different values in the same message. If you
> had purpose=sip and it goes to an ISDN GW, is it ignored? If
> it has a purpose *other* than isdn-interwork and it arrives
> at a UA other than an ISDN GW, is it ignored?
>
> It seems unreasonable to expect the sending application to
> know whether the message will be going to an ISDN GW in order
> to decide what to put into the UUI header.
>
> ISTM that the header should be useful in a natural way
> between two sip devices, and that if they suitably constrain
> their usage it should also work between two sip devices that
> are separated by an ISDN hop, or between one sip device and
> one ISDN device. That says to me that if only
> purpose=isdn-interwork makes it through an ISDN GW, then that
> is what any application that *might* interwork with ISDN will
> use, regardless of whether there is an actual use of ISDN.
>
> It seems unreasonable to me that a device that wants to use
> UUI would encode its UUI information one way for ISDN and a
> different way for sip-sip communication, in the same message.
>
> *Perhaps* it might do so in the same sense as
> multipart/alternative - where the multiple encodings are of
> the "same" information but with differing fidelity. E.g. a
> short form that fits the constraints of ISDN, and a longer
> form that that does not. In that case a recipient would use
> the "best" form it is capable of using. But the it wouldn't
> be a matter of text vs. hex.
>
>       Thanks,
>       Paul
>
> >> any sort of conversion at ISDN gateways. End-to-end transparent
> >> transport would seem to match best the intended purpose of
> the ISDN
> >> service and its use in practice.
> >>
> >> gateways. Arguably, a quoted string representation would require
> >> *less* effort by a gateway, as long as the chars are converted 1:1.
> >>
> >> The "advantage" of hex, if its the *only* encoding, is that it is
> >> done identically for every character. But its not
> especially friendly
> >> for applications or for reading message dumps.
> >>
> >> when ISDN is not involved, that might make sense. However, an ISDN
> >> gateway would not pass this on, so one would need to avoid
> using this
> >> format if expecting to interoperate with ISDN.
> >>
> >> I'm having trouble envisioning a path to use of any content other
> >> than isdn-uui or a purpose other than isdn-interwork.
> >>
> >> may or may not require isdn-interworking. That depends on the
> >> equipment deployed, and the IVR sending the UUI might not know.
> >>
> received
> >> from ISDN at UA A gets sent in exactly the same form to
> ISDN at UA B.
> >> Performing no conversion is the simplest way of achieving this.
> >>
> >> I don't think it needs to be symmetrical. There should be a single
> >> well defined sip representation for each ISDN uui value. A
> GW should
> >> always produce that value when converting from ISDN to
> sip. And a GW
> >> should of course also accept that representation and convert it
> >> consistently when going from SIP to ISDN. But there could be
> >> alternative sip representations that the GW is also capable of
> >> converting to ISDN.
> >>
> >> In that case, the preferred representation would be to
> convert each
> >> ISDN byte to corresponding quoted character when that is
> allowed, and
> >> to use \nn only when necessary. But converting the other way would
> >> presumably permit other characters to be represented using the \nn
> >> form.
> >>
> >> <flame>
> >>
> >> I am about to give up on this. I don't care *that much*. I
> was hoping
> >> to get something that seems reasonable as a native sip
> facility, that
> >> also happens to interwork with ISDN. It seems we are on a
> path that
> >> results in all the limitations and ugliness of the Q.931 mechanism
> >> with another piled on layer of ugliness and inconvenience
> to wedge it
> >> into SIP.
> >>>> detail.) Where I have been suggesting multiple purpose values, I
> >>>> think I should have been recommending different
> "content=" values.
> >>>>
> apparently
> >>>> flexible enough to do this in a non-ISDN environment.
> >>>>>
> responsible
> >>>> for determining whether it is as described by the protocol
> >>>> discriminator. So the only entities responsible for the
> usefulness,
> >>>> or not, are the two end users. As I regard any gateways
> between the
> >>>> SIP environment and the ISDN as being part of the
> network, be that
> >>>> enterprise or public, I don't see why that should end up
> having any
> >>>> determination based on the protocol discriminator value.
> ISDN will
> >>>> always have to be assumed to be binary.
> >>>>>
> >>>> IA5. I would not from my perspective have a problem if
> we encoded
> >>>> the binary as for example % escaped characters or some similar
> >>>> encoding. I suspect this would be compact for the
> majority of ISDN
> >>>> users. But I am not a user of such information, I work for a
> >>>> company that needs to transport it.
> >>>>
> >>>> That may work out in many cases, but for seriously
> binary data it
> >>>> could be quite unpleasant.
> >>>>
> >>>> For the ease of those that wish to restrict themselves
> to text and
> >>>> don't want to deal with the hex encoding, it would be
> good if the
> >>>> conversion from Q.931 to sip used the quoted string
> encoding when
> >>>> that didn't require any escaping, and otherwise use hex.
> >>>>
> >>>> specific discriminator values would cause any problem in mapping
> >>>> to/from Q.931.
> >>>>
> >>>> Fundamentally this comes down to how *sip* users of this will
> >>>> perceive it. It doesn't matter at all for Q.931 users,
> since they
> >>>> will see what they have always seen. And if you have a
> Q.931-aware
> >>>> *application* that
> >>>> has been ported to sip, *something* will still have to convert
> >>>> between the sip representation and the Q.931 format the
> >> application expects,
> >>>>>> It will lead to mistakes or errors if there is
> discretion or lack
> >>>>>> of clarity regarding the mapping. As long as the
> mapping is well
> >>>>>> defined, all should be fine.
> >>>>>>
> >>>>>> descriminator byte in the Q.931 format serves much the same
> >>>>>> purpose that the "purpose" parameter is intended to
> serve in the
> >>>>>> proposed sip uui header. It seems very natural to me
> that we make
> >>>>>> this correlation.
> >>>>>>
> >>>>>> I guess the counter-argument to that is *if* the
> prevailing use
> >>>>>> of UUI in ISDN entirely ignores the intent of the
> discriminator
> >>>>>> byte, and simply uses the entire string, including the
> >>>>>> discriminator byte, as a single data value. I don't
> know if that
> >>>>>> might be the case, or not. (I hope not, since it is a
> gross abuse
> >>>>>> of the Q.931 spec.)
> >>>>>>
> appreciate
> >>>>>> being forced to convert text data to/from hex for this
> purpose.
> >>>>>> It certainly it won't be well appreciated by those looking at
> >>>>>> call traces. While its perhaps unavoidable when the
> actual data
> >>>>>> is binary, it is avoidable when the data is itself text.
> >>>>>>
> >>>>>>   Thanks,
> >>>>>>   Paul
> >>>>>>
> >>>>>>>      - Alan -
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> escapes, then represent it that way, else represent it
> as hex."
> >>>>>> And the converse conversion could be "convert a sip
> quoted string
> >>>>>> to Q.931 byte for byte, and convert hex to
> >>>>>> possibly by the protocol discriminator. Moreover in
> the ISDN, the
> >>>>>> protocol discriminator could just be a lie. Noone
> checks it from
> >>>>>> one end to the other, and it has no impact on the way
> the network
> >>>>>> provides the service.
> >>>>>>>>>
> >>>>>> application is always map to a binary coding within the header
> >>>>>> field. What that tranfer coding is could be optimised
> so one size
> >>>>>> fits all as we discussed previously on the list.
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>>
> >>>>>>>>> Keith
> >>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Feb 2011 15:05:42 -0500

> That expectation is expressed in different words: The sender purposefully restricts themselves to the limitations of the ISDN application in order that if interworking occurs with the ISDN, the int…

There is a big difference between "accepting the limitations of ISDN" 
and "knowing this is going to ISDN". This is especially the case if 
"purpose=isdn-interwork" really means it should only be processed by an 
ISDN GW and some other purpose is to be used in all other cases.

I'd really like to understand the thinking about how the purpose 
parameter is intended to be used.

	Thanks,
	Paul