Cullen Jennings wrote:
On Nov 17, 2008, at 10:22 , Alan Johnston wrote:
Cullen,
Keith is correct - this is not about mapping ISDN parameters into SIP,
it is about mapping a very successful and popular ISDN *service* into
SIP.
Fair enough - I agree with you and Keith on this.
This is precisely my concern. By doing this we are adopting this syntax
for carrying data for what will eventually be *SIP* services. Is this
*really* the way we want to support those services in a native sip
environment?
Once its done it will not make sense to develop a different syntax for
native sip use.
If we go this way, every sip entity that needs to deal with these will
need to have the needed ASN.1 encoding/decoding logic. I don't know if
that is trivial to special case because I don't know what all the
various formats are. But it would at least be annoying.
Thanks,
Paul
Until we solve this with an appropriate mechanism, SIP will not
make headway into areas such as contact centers.
And, there is a limit on the size of data - please read the draft.
Hmm - you are right that when I read it, I had missed the key part of
Note that ISDN limits UUI to 128 octets in length. While this header
field has no such limitations, transporting UUI longer than 128
octets will result in interoperability failures when interworking
with ISDN.
And the draft says nothing about proxy inspection and routing. I
mentioned it in my email because we know that clever implementors will
do clever things.
The draft is not making the arguments you specify.
So, if I remove the text in your comments about this being an ISDN
parameter mapping issue, the size being unlimited, and problematic proxy
behavior, I don't think there are any remaining issues.
If you have issues with the requirements in the draft, let us know so we
can clarify them.
I can easily imagine cases where customer sensitize information was
transfered over this and it was going to an remote agent phone that went
through another trust domain to route the call to the agent. In these
cases, I think an important requirement would be to protect the draft
from authorized access by intermediaries.
Cullen in my individual contributor role
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
