I do not want a P-header. It would not meet the requirements of the
industry.
I do think, however, that we can finish this work quickly (unless our
process breaks down completely). I mean, these are simple, simple
requirements.
If others such as Henry want a more expansive mechanism for application
users of SIP, then it would be interesting to start work on new
requirements in SIPPING and see where it takes us. However, this work
is clearly separate - one should not hold up the other.
Thanks,
Alan
DRAGE, Keith (Keith) wrote:
To publish as informational under the current IANA registration procedures would mean that the solution would need to be downgraded to a P-header, and the option tag would need to be removed. The option tag is there to meet one of the ISDN interworking requirements, as it is possible to say in DSS1 that the call should only proceed in the UUI is understood - i.e. interworking capability will be lost.
Do others share Henry's view, or should this document ultimately proceed in SIP as a standards track document, with the proposed new header field and option tag.
regards
Keith
-----Original Message-----
From: Henry Sinnreich [mailto:hsinnrei@xxxxxxxxx]
Sent: Friday, November 21, 2008 2:45 PM
To: DRAGE, Keith (Keith); Joanne McMillen; Paul Kyzivat;
Cullen Jennings; Laura Liess
Cc: sipping; Huelsemann,Martin
Subject: Re: draft-johnston-sipping-cc-uui-05
Keith,
what protocols other than those carried by ISDN did you want to map
over SIP.
This is a good question and allows me to clarify two points:
* Since the I-D <draft-johnston-sipping-cc-uui> is
solving a real problem for some people, it should be
published as an informational RFC ASAP. Far too much design
by committee has already been perpetrated :-)
* As for what other protocols to map over SIP, please
recall our I-D on "simple SIP": The option to use SIP only
for rendezvous and session setup negotiation. Simple SIP
solves we believes this (send data along with a call
transfer) and other requirements as well over IP networks and
over the Internet.
Henry
On 11/20/08 9:27 PM, "DRAGE, Keith (Keith)"
<drage@xxxxxxxxxxxxxxxxxx> wrote:
So to Henry - what protocols other than those carried by ISDN
did you want to map over SIP.
I would argue that in an entirely SIP environment, this would
be either using SIP as a transport protocol, and therefore
incorrect, or that the mechanisms already exist in such an
environment for carry things like MESSAGE which solve this problem.
The ISDN issue is that this transport is already embedded in
a call control message, and therefore by splitting it out,
you would lose the coupling semantic that exists in the ISDN
protocol. Therefore ISDN has an interworking case where there
is a need to do this.
Does the interworking with any other protocol generate such a
need where we could see the need to extend the current requirements.
regards
Keith
-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Henry Sinnreich
Sent: Thursday, November 20, 2008 9:21 PM
To: Joanne McMillen; Paul Kyzivat; Cullen Jennings; Laura Liess
Cc: sipping; DRAGE, Keith (Keith); Huelsemann,Martin
Subject: Re: draft-johnston-sipping-cc-uui-05
Joanne,
Can we eliminate the "futures" discussion here for that
"other track" and just deal with the immediate need please?
This is new to me: IP networks (such as inside contact centers,
enterprises) and the Internet are futures? :-)
But I do not intend to press this any further.
Henry
On 11/20/08 1:17 PM, "Joanne McMillen" <joanne@xxxxxxxxx> wrote:
I can tell you what one author thinks Henry. ;-)
Like Laura and others have stated - we have an immediate need here.
Where this may go in the future with enhanced definitions
in SIP is
future consideration.
We all agree (I suspect) that SIP can be far more robust
here for this
"functionality".
When and if someone wants to define what that new and robust
"functionality" is in SIP it would beg the question as to
whether or
not this specific header for UUI is the right avenue for that.
It could be and it couldn't be - I can see that debate going either
way and for very good reasons for going either way.
The bottom line is we have an immediate need right now that
this draft
addresses - I do not want to see this get bogged down by future
concerns - and the definition allows for that if anyone chooses to
extend it going forward in SIP...
Can we eliminate the "futures" discussion here for that
"other track"
and just deal with the immediate need please?
Thanks,
Joanne
----- Original Message -----
From: Henry Sinnreich <mailto:hsinnrei@xxxxxxxxx>
To: Laura Liess <mailto:Laura.Liess@xxxxxx> ; Cullen Jennings
<mailto:fluffy@xxxxxxxxx> ; Paul Kyzivat
<mailto:pkyzivat@xxxxxxxxx>
Cc: sipping <mailto:sipping@xxxxxxxx> ; Joanne McMillen
<mailto:joanne@xxxxxxxxx> ; DRAGE, Keith (Keith)
<mailto:drage@xxxxxxxxxxxxxxxxxx> ; Huelsemann, Martin
<mailto:Martin.Huelsemann@xxxxxxxxxx>
Sent: Thursday, November 20, 2008 11:37 AM
Subject: Re: draft-johnston-sipping-cc-uui-05
1) Get this syntax agreed as soon as possible because it
is needed
by the industry in the today's PSTN/SIP mixed environment.
Well, I have here to make the observation that SIP-PSTN is not the
only mixed environment.
SIP is also used on IP networks and on the Internet and
the UUI may
look there vastly more different - probably extensible and very
powerful. And it may be just as urgent.
So it appears the SIP UUI may end up with two tracks, one for
compatibility with ISDN and the other for the IP networks and the
Internet.
What do the authors think?
Henry
On 11/20/08 9:03 AM, "Laura Liess" <Laura.Liess@xxxxxx> wrote:
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?
Paul,
I do not see why we should not do both and leave the
decision to the
market.
IETF did this in the past.
1) Get this syntax agreed as soon as possible because it is
needed by the industry in the today's PSTN/SIP mixed
environment. If
we do not come up very soon with a standard, people will use
proprietary extenssions. I think we should avoid this.
There are no
technical reasons not to move on with the draft.
2) In the long term we could develop a "native sip"
syntax which is more flexible, easier to implement,
whatever.... It
will have advantages in a "sip native"
environment and it will be adopted when the "native sip"
environement is in place.
Laura
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
_______________________________________________
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
_______________________________________________
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
