Subject: [RAI] Fwd: SIPREAL BOF proposal for IETF 70

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Oct 2007 20:11:38 -0700

Just wanted to let folks know Jon and I received the following BOF  
proposal.

Begin forwarded message:

>
>
> SIPREAL - SIP REAL-World Interoperability Experiences
> -----------------------------------------------------
>
> Chairs:
>   TBD
>
> IETF has been working on SIP standards for over ten years. Over  
> time the
> pile of SIP-related specifications has grown at rapid rate, as  
> depicted
> in http://www.rfc3261.net/. There are dozens of client and
> proxy/registrar implementations of SIP, and at least hundreds of
> independent deployments of non-trivial scale. However, for some  
> reasons
> SIP has not yet reached the target state where one could just pick any
> User Agent and succesfully use it with any SIP service provider on the
> Internet, as could be expected from any "true" Internet protocol.  
> There
> are probably many non-technical reasons for this as well, but
> interoperability problems are a significant factor. One often  
> encounters
> statements that many implementations still have challenges even  
> with the
> basic functionality like registration, authentication and session
> establishment. More complicated features such as video calls or  
> presence
> currently seem rarely work between different implementations.
>
> While there are other organizations, such as SIP Forum
> (http://www.sipforum.com), who arrange interoperability events and do
> other work to promote interoperability in general, the IETF itself
> should also live to its slogan "rough consensus and RUNNING CODE".
> Indeed many people who implement, test or deploy SIP do participate in
> the IETF, but for some reason this is NOT happening nearly to the  
> extent
> as there is such activity around SIP in general. The IETF should
> encourage this type of contribution to improve its standards. In the
> last couple of years the IETF RAI area has established a couple of
> Working Groups, BLISS and SPEERMINT, to address interoperability
> problems. These are however operating on a purposely narrow charter  
> on a
> few specific issues.
>
> The SIPREAL BOF is intended to present and discuss issues  
> encountered in
> real-world SIP implementations, deployments and interoperability  
> testing
> for the benefit of IETF standardization community. The aim is to
> activate the implementers and give them a channel to get their message
> across. The aim is also to give the IETF community a better picture
> which parts of SIP are implemented and stable, and which are not. In
> case the BOF identifies and agrees on specific issues, those should be
> documented but the actual standards work (standards track, BCP,
> informational documents) should be chartered by existing WGs such as
> SIP/SIPPING, MMUSIC, SIMLE or BLISS. The BOF does NOT aim at forming a
> new WG or producing any standards work on its own. If the BOF is
> succesful, similar session can be repeated also in future IETF  
> meetings.
> If not, the IETF should think about better ways of meeting similar
> goals.
>
> Agenda (presentations based on request and availability):
> - Discussion: how should the IETF activate the implementors/deployer
> community to contribute more
> - Feedback from SIP test events and testing activities
> - Presentations by SIP service providers on real SIP deployments
> - Presentations by SIP implementers/vendors on their interoperability
> experiences
> - Presentations on open source SIP projects and their experiences
> - Conclusions

_______________________________________________
RAI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rai

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Oct 2007 00:22:56 -0400

Just why... why ? Isnt this just a natural extension of the SIP WG itself?

SIPit is just doing fine. 

I'm all for a BOF on any reasonable subject and this a reasonable subject to
have BOF on. So OK for the general principal.

The problem IMHO is very simple.

There is no real architecture for SIP. We all have heard the stories from
implementers that say " what do I do" "what RFC's do I implement". It's a
moving target unlike ITU <gag> standards that present a unified
implementable profile of protocols.

Can the SIP WG be re-chartered to actually give implementers a real
direction on what they need to do. Can we create version "profiles"?

The hitchhikers guide is something but it's too amorphous to be practical.

I personally dealt with this issue when the SIPforum dealt with the issue of
IP-PBX to Service provider recommendations aka SIPconnect which I had the
personal privilege of chairing.

 http://www.sipforum.org/sipconnect

I don't get what is the difference between this work and BLISS which I still
don't completely understand.

>  -----Original Message-----
>  From: Cullen Jennings [mailto:[email-masked]]
>  Sent: Wednesday, October 17, 2007 11:12 PM
>  To: [email-masked]
>  Subject: [RAI] Fwd: SIPREAL BOF proposal for IETF 70
>  
>

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 17 Oct 2007 23:33:06 -0500

Hi, Richard,

I am not channeling anyone on this point, but

(1) what I'm hoping for is documents that describe basic SIP functionality 
that gets mis-implemented in the real world, and

(2) my understanding is that BLISS is about feature group functionality 
interoperability when all of the implementations comply with the 
specifications, and SIPREAL is about basic SIP functionality in 
implementations that does NOT comply with the specifications.

Thanks,

Spencer

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 18 Oct 2007 01:10:18 -0400

Spencer thanks for chiming in here ...but my point is that the levels of
complexity and responsible WG's being proposed here making are already
making implementations very difficult and some clarity is necessary. 

Its bad enough that some "other standards bodies"[who shall remain nameless]
throw over the transom requirements that we're sadly required to
accommodate. 

This is a fundamental architecture issue. Who is responsible for making SIP
work ? That IMHO is the issue underlying this BOF proposal. A discussion
over that issue is IMHO completely responsible and appropriate for a BOF to
consider.

>  From: Spencer Dawkins [mailto:[email-masked]]
>  Sent: Thursday, October 18, 2007 12:33 AM
>  To: [email-masked]
>  Subject: Re: [RAI] Fwd: SIPREAL BOF proposal for IETF 70
>  
>  Hi, Richard,
>  
>  > I'm all for a BOF on any reasonable subject and this a reasonable
>  subject
>  > to
>  > I personally dealt with this issue when the SIPforum dealt with the
>  issue
>  > of
>  > I don't get what is the difference between this work and BLISS which
>  I
>  > still
>  >>  > SIP has not yet reached the target state where one could just
>  pick
>  >>  any
>  >>  > User Agent and succesfully use it with any SIP service provider
>  on
>  >>  the
>  >>  > (http://www.sipforum.com), who arrange interoperability events
>  and
>  >>  do
>  >>  > Indeed many people who implement, test or deploy SIP do
>  participate
>  >>  in
>  >>  > case the BOF identifies and agrees on specific issues, those
>  should
>  >>  be
>  >>  > SIP/SIPPING, MMUSIC, SIMLE or BLISS. The BOF does NOT aim at
>  forming
>  >>  a

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Oct 2007 02:59:52 -0500

> direction on what they need to do. Can we create version "profiles"?

nah, we're too busy figuring out where we went Wrong to figure out  
what implementations should do to be Right.

Seriously, I think this BOF is about a forum where people can rap  
about where the SIP specs are broken, or at least where they  
misunderstood them, and get back to SIP with ideas about fixes. I  
wouldn't mind doing this in SIP, but frankly, there just hasn't been  
time. Obviously, that's a priority question.

--
Dean

---

From: [email-masked]
Date: Thu, 18 Oct 2007 10:01:03 +0200

Just a naif comment from a naif person: I like this BOF, even though,  

>> community to contribute more

- Discussion: how should the IETF activate ITSELF in order to give the  
right space to implementers/deployer community.

I personally attend IETF meetings since a while and I keep on seeing  
just a bit of rough consensus and almost zero running code.

Cheers,

Simon

Quoting Cullen Jennings <[email-masked]>:

>
> Just wanted to let folks know Jon and I received the following BOF proposal.
>
> Begin forwarded message:
>
>>
>>
>> IETF has been working on SIP standards for over ten years. Over time the
>> pile of SIP-related specifications has grown at rapid rate, as depicted
>> independent deployments of non-trivial scale. However, for some reasons
>> Internet, as could be expected from any "true" Internet protocol. There
>> interoperability problems are a significant factor. One often encounters
>> statements that many implementations still have challenges even with the
>> establishment. More complicated features such as video calls or presence
>> the IETF, but for some reason this is NOT happening nearly to the extent
>> problems. These are however operating on a purposely narrow charter on a
>> few specific issues.
>>
>> The SIPREAL BOF is intended to present and discuss issues encountered in
>> real-world SIP implementations, deployments and interoperability testing
>> succesful, similar session can be repeated also in future IETF meetings.

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: <[email-masked]>
Date: Thu, 18 Oct 2007 11:41:34 +0300

Hi,

I wouldn't mind arranging something as part of SIP or SIPPING
agenda/charter as opposed to a separate BOF, that's not so important.
The problem overall seems to be that all RAI WGs are very busy during
the meeting week. (Well, I don't know if yet-another-SIP-related-session
will help with that...)

But for me the main point would be to figure out if there's anything
more we could do in the IETF to get real-world feedback from
implementors and service providers. A dedicated BOF session was my
initial idea and there has been some support for it. There might be
better ways. 

Perhaps the issue should be formulated in two parts: 

1) Do people think that there is an issue with not getting enough
implementer feedback to the IETF SIP work, and do they also think it is
*realistically possible* to improve this somehow. (So it's not only
wishful thinking that will never lead to anything concrete.)

2) What are the realistic and concrete improvements

If there's consensus about 1) it makes sense to work on 2).

Markus

PS. I'm definitely not forgetting SIP Forum and SIPit. Perhaps this
would be an opportunity to highlight their role and relation to IETF
more. 

>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 18 October, 2007 11:00
>To: Richard Shockey
>Cc: [email-masked]
>nah, we're too busy figuring out where we went Wrong to figure 
>out what implementations should do to be Right.
>
>Seriously, I think this BOF is about a forum where people can 
>rap about where the SIP specs are broken, or at least where 
>they misunderstood them, and get back to SIP with ideas about 
>fixes. I wouldn't mind doing this in SIP, but frankly, there 
>just hasn't been time. Obviously, that's a priority question.
>
>--
>Dean
>
>
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 18 Oct 2007 11:00:41 +0200

If that is a comments on the hitchhiker's guide (currently in WGLC), can
you make it on the SIP list - and also make some practical suggestions
how it cannot be "amorphous".

The function of the hitchhikers guide was obviously to do some of what
you want, and it is apparently not meeting your expectations.

Regards

Keith 

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Thursday, October 18, 2007 5:23 AM
> To: 'Cullen Jennings'; [email-masked]
> Subject: RE: [RAI] Fwd: SIPREAL BOF proposal for IETF 70
> 
> I'm all for a BOF on any reasonable subject and this a 
> reasonable subject to have BOF on. So OK for the general principal.
> 
> There is no real architecture for SIP. We all have heard the 
> stories from implementers that say " what do I do" "what 
> RFC's do I implement". It's a moving target unlike ITU <gag> 
> standards that present a unified implementable profile of protocols.
> 
> Can the SIP WG be re-chartered to actually give implementers 
> a real direction on what they need to do. Can we create 
> version "profiles"?
> 
> I personally dealt with this issue when the SIPforum dealt 
> with the issue of IP-PBX to Service provider recommendations 
> aka SIPconnect which I had the personal privilege of chairing.
> 
> I don't get what is the difference between this work and 
> BLISS which I still don't completely understand.
> 
> 
> >  > SIPREAL - SIP REAL-World Interoperability Experiences  > 
> >  > IETF has been working on SIP standards for over ten 
> years. Over  > 
> > time the  > pile of SIP-related specifications has grown at rapid 
> > rate, as  > depicted  > in http://www.rfc3261.net/. There 
> are dozens 
> > of client and  > proxy/registrar implementations of SIP, 
> and at least 
> > hundreds of  > independent deployments of non-trivial 
> scale. However, 
> > for some  > reasons  > SIP has not yet reached the target 
> state where 
> > one could just pick  any  > User Agent and succesfully use 
> it with any 
> > SIP service provider on  the  > Internet, as could be expected from 
> > any "true" Internet protocol.
> >  > There
> >  > are probably many non-technical reasons for this as well, but  > 
> > interoperability problems are a significant factor. One often  > 
> > encounters  > statements that many implementations still have 
> > challenges even  > with the  > basic functionality like 
> registration, 
> > authentication and session  > establishment. More 
> complicated features 
> > such as video calls or  > presence  > currently seem rarely work 
> > between different implementations.
> >  >
> >  > While there are other organizations, such as SIP Forum  > 
> > in  > the IETF, but for some reason this is NOT happening nearly to 
> > the  > extent  > as there is such activity around SIP in 
> general. The 
> > IETF should  > encourage this type of contribution to improve its 
> > standards. In the  > last couple of years the IETF RAI area has 
> > established a couple of  > Working Groups, BLISS and SPEERMINT, to 
> > address interoperability  > problems. These are however 
> operating on a 
> > purposely narrow charter  > on a  > few specific issues.
> >  >
> >  > The SIPREAL BOF is intended to present and discuss issues  > 
> > encountered in  > real-world SIP implementations, deployments and 
> > interoperability  > testing  > for the benefit of IETF 
> standardization 
> > community. The aim is to  > activate the implementers and 
> give them a 
> > channel to get their  message  > across. The aim is also to 
> give the 
> > IETF community a better picture  > which parts of SIP are 
> implemented 
> > and stable, and which are not. In  > case the BOF identifies and 
> > agrees on specific issues, those should  be  > documented but the 
> > actual standards work (standards track, BCP,  > informational 
> > documents) should be chartered by existing WGs such as  > 
> SIP/SIPPING, 
> > MMUSIC, SIMLE or BLISS. The BOF does NOT aim at forming  a  
> > new WG 
> > or producing any standards work on its own. If the BOF is  > 
> > succesful, similar session can be repeated also in future IETF  > 
> > meetings.
> >  > - Discussion: how should the IETF activate the 
> > implementors/deployer  > community to contribute more  > - Feedback 
> > from SIP test events and testing activities  > - 
> Presentations by SIP 
> > service providers on real SIP deployments  > - Presentations by SIP 
> > implementers/vendors on their  interoperability  > experiences  > - 
> > Presentations on open source SIP projects and their 
> experiences  > - 
> > Conclusions
> >

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 18 Oct 2007 11:27:45 +0200

> >There are dozens of client and proxy/registrar implementations of
> >SIP, and at least hundreds of independent deployments of non-trivial
> >scale. However, for some reasons SIP has not yet reached the target
> >state where one could just pick any User Agent and succesfully use it
> >with any SIP service provider on the Internet, as could be expected
> >from any "true" Internet protocol.

My experience with UA / SIP operators interworking isn't that bad,
at least if compared to what I see when I try cross-provider SIP calls.

So: Is this BOF explicitly restricted to intra-provider issues
(UAs talking to VoIP operators) or is it supposed to cover
inter-provider calls as well?

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Oct 2007 08:20:09 -0400

The problem is generally inter-vendor, i.e., SIP UA from vendor A  
talking to proxy/gateway/UA/SBC/... from vendor B. There are problems  
even with basic functionality. As a random example, implementors seem  
very confused as to how to handle Digest authentication, making  
choices that make interoperability impossible or configuration  
extremely confusing (since you have to type in very different values  
for what seems like the same field). With permission, I'm forwarding  
a message from Phil Karn, hardly an Internet novice, that sent me a  
rant a few days ago:

> Hi Henning,
>
> You may remember me from IETFs past -- I haven't attended any in some
> time because I couldn't find any really interesting projects.
>
> I'm finally getting into SIP. I've got Speakeasy VoIP service, two
> sipphone accounts, a Cisco 7960 and a copy of x-ten on my Mac.
>
> And I still can't make it work. Voice flows in one direction only. I'm
> not even behind a NAT or firewall -- both machines have global
> addresses, with no port translations or firewalls.
>
> I've been working with Internet protocols for over 20 years. I've
> implemented and contributed to them. And if *I* can't figure out  
> how to
> make this stuff work, how is the average grandmother expected to do  
> so?
> SIP is unbelievably complex, with extraordinarily confusing terms.  
> There
> must be half a dozen different "names" -- Display Name, User Name,
> Authorization User Name, etc -- and a dozen "proxies". Even the word
> "domain" is overloaded a half dozen different ways. This is  
> ridiculous!
>
> Sorry. I just had to get this off my chest. Regards,

We investigated the problem - turns out to be a case of mis-handling  
non-standard port numbers and non-symmetric SIP requests. We're well  
below BLISS complexity here - this is just a basic SIP INVITE. These  
types of problems are not currently addressed in the call flows or  
torture test documents, unfortunately.

Henning

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 18 Oct 2007 07:52:06 -0500

Hi, Henning,

Thanks for sending Phil's note as background - and your point about "well 
below the complexity of BLISS" is what I was trying to say in my previous 
note.

Spencer

> The problem is generally inter-vendor, i.e., SIP UA from vendor A  talking 
> to proxy/gateway/UA/SBC/... from vendor B. There are problems  even with 
> basic functionality. As a random example, implementors seem  very confused 
> as to how to handle Digest authentication, making  choices that make 
> interoperability impossible or configuration  extremely confusing (since 
> you have to type in very different values  for what seems like the same 
> field). With permission, I'm forwarding  a message from Phil Karn, hardly 
> an Internet novice, that sent me a  rant a few days ago:
>
>> Hi Henning,
>>
>> implemented and contributed to them. And if *I* can't figure out  how to
>> make this stuff work, how is the average grandmother expected to do  so?
>> SIP is unbelievably complex, with extraordinarily confusing terms.  There
>> "domain" is overloaded a half dozen different ways. This is  ridiculous!
>>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 18 Oct 2007 08:00:45 -0500

Hi, Keith,

I have reviewed previous versions of the hitchhiker's guide (and it looks 
like I'll be doing a re-review Really Soon Now), and I thought the 
relationship between the hitchhiker's guide and SIPREAL was that the 
hitchhiker's guide helped you decide what to implement while SIPREAL was 
focused on what people tend to get wrong when they do implement.

Neither of these are quite what I thought Richard was talking about - given 
that we have 110 or so RFCs that "define SIP", and a hitchhiker's guide that 
explains them,

- what should people implement, and

- (this is harder) what's the architecture for SIP ("is it a transport 
protocol or an application protocol", to take one current SIP list example), 
so we know how to do extensions and whether to say "yes" or "no" to 
proposals for extensions.

Richard, did I get this right?

Thanks,

Spencer

----- Original Message ----- 
From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "Richard Shockey" <[email-masked]>; "Cullen Jennings" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, October 18, 2007 4:00 AM
Subject: RE: [RAI] Fwd: SIPREAL BOF proposal for IETF 70

Regards

Keith

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 18 Oct 2007 11:26:35 -0500

I don't see anything wrong with a BOF on this topic, even if the outcome
is that we decide that the best way to handle interop is through the 
working groups, in particular SIP, BLISS (and maybe SIPPING).

At least we will have the discussion.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 18 Oct 2007 09:58:09 -0700

Actually Richard has here a great point, so I will put it on top:

1. Who is responsible for SIP on the Internet? (Hint: The IETF)

2. Does the IETF care (focus and resources) about the (mis)use of SIP in
walled gardens? (Hint: Absolutely not)

3. Must the SIP work in be IETF Internet/e2e compliant? (Hint: Sure)

4. Must standards proposals be backed up by code and deployment
experience?
(Hint: Sure, here is why...)

Thanks, Henry

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2007 10:10 PM
To: 'Spencer Dawkins'; [email-masked]
Subject: RE: [RAI] Fwd: SIPREAL BOF proposal for IETF 70

Its bad enough that some "other standards bodies"[who shall remain
nameless]
throw over the transom requirements that we're sadly required to
accommodate. 

This is a fundamental architecture issue. Who is responsible for making
SIP
work ? That IMHO is the issue underlying this BOF proposal. A discussion
over that issue is IMHO completely responsible and appropriate for a BOF
to
consider.

>  > There is no real architecture for SIP. We all have heard the
stories
>  from
>  >>  > encourage this type of contribution to improve its standards.
In
>  implementors/deployer

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 18 Oct 2007 12:20:57 -0500

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Thursday, October 18, 2007 11:58 AM
> To: Richard Shockey; Spencer Dawkins; [email-masked]
> 2. Does the IETF care (focus and resources) about the 
> (mis)use of SIP in walled gardens? (Hint: Absolutely not)

I don't agree with your hint at all. 

If a vast number of SIP devices in upcoming years are going to be
defined and connected/reachable only through non-IETF defined usages of
SIP, then it needs to be addressed. There's no benefit to ignoring the
elephant in the room in terms of ensuring interoperability. We have RFCs
that describe how to interwork/tunnel SIP with ISUP. I don't want to
have to address the need to interwork/tunnel SIP using SIP so I can work
with all of those devices that have no choice but to work within the
model they are given service through.

We want to get rid of the gateways eventually, remember?

Regards,
Brian

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 18 Oct 2007 10:52:38 -0700

Brian,

> There's no benefit to ignoring the elephant in the room in terms of 
> ensuring interoperability.

Elephants belong on the reservation.

By limiting to SIP on the Internet, probably 90% of the reported
problems can be dealt with in the reservations.

Sure, the interoperability and other problems should be dealt with, but
by the walled garden architects who brought all this about.

Henry

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 10:21 AM
To: Henry Sinnreich; Richard Shockey; Spencer Dawkins; [email-masked]
Subject: RE: [RAI] Fwd: SIPREAL BOF proposal for IETF 70

Regards,
Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Oct 2007 14:39:40 -0400

I think what you describe is distinct from the "interoperability problems" type thing that the BOF Proposal described, as I read it.

You're talking about "profiles", as in "You should implement RFCs ABC and XYZ"... right?  Whereas I read the BOF as wanting to get info such as: "We've found RFC ABC has the following interop problems in the real world".

Those are two very different conversations.  "Profiles" needs an architecture view, as you say, but I doubt the IETF is the right place for that.  It will get us nowhere.  Interop issues of RFCs is a much healthier subject. :)

Like for example, we see interop issues all the time with things like: offerless Invites, offerless re-Invites, REFER handling, call-hold, Register response handling, Invite response handling, e164 tel and sip username syntax, header and parameter length limits, ignoring unknown headers and parameters, and many more.  And that's not even touching on SDP, RTP, and XML body interop issues.  Unfortunately, quite a lot of the interop problems we've found are with vendors who do not attend the IETF.  And some of them have been things that vendors allow to be configurable, which is its own interop problem space.

-hadriel

> Sent: Thursday, October 18, 2007 12:23 AM

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 20 Oct 2007 16:07:01 -0400

We're starting to put together a set of automated tests. If folks can  
provide concrete examples of issues such as the ones below, we can  
start integrating them into the test suite.

On Oct 19, 2007, at 2:39 PM, Hadriel Kaplan wrote:

> I think what you describe is distinct from the "interoperability  
> problems" type thing that the BOF Proposal described, as I read it.
>
> You're talking about "profiles", as in "You should implement RFCs  
> ABC and XYZ"... right?  Whereas I read the BOF as wanting to get  
> info such as: "We've found RFC ABC has the following interop  
> problems in the real world".
>
> Those are two very different conversations.  "Profiles" needs an  
> architecture view, as you say, but I doubt the IETF is the right  
> place for that.  It will get us nowhere.  Interop issues of RFCs is  
> a much healthier subject. :)
>
> Like for example, we see interop issues all the time with things  
> like: offerless Invites, offerless re-Invites, REFER handling, call- 
> hold, Register response handling, Invite response handling, e164  
> tel and sip username syntax, header and parameter length limits,  
> ignoring unknown headers and parameters, and many more.  And that's  
> not even touching on SDP, RTP, and XML body interop issues.   
> Unfortunately, quite a lot of the interop problems we've found are  
> with vendors who do not attend the IETF.  And some of them have  
> been things that vendors allow to be configurable, which is its own  
> interop problem space.

---

From: Adam Roach <[email-masked]>
Date: Sat, 20 Oct 2007 15:42:09 -0500

The biggest problem I've seen in getting real-life deployments of 
non-trivial SIP networks working is clients that cannot authenticate 
with two entities for a single request. For example, I've found that the 
preponderance of hard phones and ATAs (yes, I mean more than a simple 
majority) cannot deal with the following scenario:

       Caller            Proxy 1           Proxy 2           Callee
          |(1) INVITE       |                 |                 |
          |---------------->|                 |                 |
          |(2) 407          |                 |                 |
          |<----------------|                 |                 |
          |(3) ACK          |                 |                 |
          |---------------->|                 |                 |
          |(4) INVITE       |                 |                 |
          |---------------->|                 |                 |
          |                 |(5) INVITE       |                 |
          |                 |---------------->|                 |
          |                 |(6) 407          |                 |
          |                 |<----------------|                 |
          |                 |(7) ACK          |                 |
          |                 |---------------->|                 |
          |(8) 407          |                 |                 |
          |<----------------|                 |                 |
          |(9) ACK          |                 |                 |
          |---------------->|                 |                 |
          |(10) INVITE      |                 |                 |
          |---------------->|                 |                 |
          |                 |(11) INVITE      |                 |
          |                 |---------------->|                 |
          |                 |                 |(12) INVITE      |
          |                 |                 |---------------->|
          |                 |                 |(13) 200         |
          |                 |                 |<----------------|
          |                 |(14) 200         |                 |
          |                 |<----------------|                 |
          |(15) 200         |                 |                 |
          |<----------------|                 |                 |
          |(16) ACK         |                 |                 |
          |---------------->|                 |                 |
          |                 |(17) ACK         |                 |
          |                 |---------------->|                 |
          |                 |                 |(18) ACK         |
          |                 |                 |---------------->|

Many give up after seeing message 8. I've seen some that go into an loop 
(1 through 9 then back to 1) -- sometimes infinite -- because they send 
only one set of credentials at a time. Proper behavior here is very well 
defined, but for some reason implementors seem to get it wrong most of 
the time.

It's really not possible to deploy anything other than a very, very 
simple network or a closed garden without support for this kind of 
authentication model.

/a

Henning Schulzrinne wrote:
>> You're talking about "profiles", as in "You should implement RFCs ABC 
>> and XYZ"... right?  Whereas I read the BOF as wanting to get info 
>> such as: "We've found RFC ABC has the following interop problems in 
>> the real world".
>>
>> place for that.  It will get us nowhere.  Interop issues of RFCs is a 
>> much healthier subject. :)
>>
>> like: offerless Invites, offerless re-Invites, REFER handling, 
>> call-hold, Register response handling, Invite response handling, e164 
>> with vendors who do not attend the IETF.  And some of them have been 
>> things that vendors allow to be configurable, which is its own 
>> interop problem space.
>
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 04:27:28 -0500

You can implement a federation between proxy 1 and proxy 2 with that
(broken) model. I've seen plenty of those.

Another issue is that implementations are frequently deployed where the
local outbound proxy is also their registrar (or so it appears for
capacity reasons). If you're writing a digest authentication routine,
and the first time it gets hit is during registration (when you first
log in and enter your password on the client) then you probably think
everything is working fine in the general case as well.

I think this is more a lack of imagination on the part of implementors
and testers than anything else. Everything works in their development
environment because it has only one proxy or the proxies are configured
to trust one another and so message 6 never arrives.

I know from my own personal experience that it was many years before we
ran into a two-realm digest authentication deployment and discovered we
suffered from the same endless loop issue. In that particular instance
it arose because someone else forgot to configure the proxies to trust
one another.

Because there are not a lot of usecases given for a particular
requirement in the RFCs, everyone has to go out and imagine the possible
interactions that may occur, separately from one another. Imaginations
vary in quantity and quality, so you get what you get. This is why
including examples in a document can be such a two-edged sword: on the
one hand it helps clarify the text so you get better implementations,
but on the other it entices people to code to the example.

Some people don't equate 'example' with 'non-normative'. They think the
example was written by the same group of folks who wrote the text so it
has to be a correct and *complete* capture of all the normative
statements in the document. A picture is worth a thousand bugs.

I think a great many people would have much more success if they always
tested and coded with the assumption that there may always be at least
two proxies in the loop. For one thing, it forces you to re-encode all
of your assumptions back into SIP for someone else to figure out without
the assistance of global variables.

Regards,
Brian

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Saturday, October 20, 2007 3:42 PM
> To: Henning Schulzrinne
> Cc: [email-masked]; Hadriel Kaplan
> The biggest problem I've seen in getting real-life 
> deployments of non-trivial SIP networks working is clients 
> that cannot authenticate with two entities for a single 
> request. For example, I've found that the preponderance of 
> hard phones and ATAs (yes, I mean more than a simple
> (1 through 9 then back to 1) -- sometimes infinite -- because 
> they send only one set of credentials at a time. Proper 
> behavior here is very well defined, but for some reason 
> implementors seem to get it wrong most of the time.
> 
> It's really not possible to deploy anything other than a 
> very, very simple network or a closed garden without support 
> for this kind of authentication model.
> 
> /a
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 Oct 2007 12:02:04 -0700

I have some similar frustrations to Phil. I actually think that is  
more a problem with a lack of a usable configuration framework and  
data model than anything to do with Digest authentication. We have  
needed something in the configuration space for a long time - even  
just common terminology on what the various fields are called would  
be an improvement. I really hope we can get the configuration  
framework and and data model work completed.

Cullen <with my individual hat on>

On Oct 18, 2007, at 5:20 AM, Henning Schulzrinne wrote:

> talking to proxy/gateway/UA/SBC/... from vendor B. There are  
> problems even with basic functionality. As a random example,  
> implementors seem very confused as to how to handle Digest  
> authentication, making choices that make interoperability  
> impossible or configuration extremely confusing (since you have to  
> type in very different values for what seems like the same field).  
> With permission, I'm forwarding a message from Phil Karn, hardly an  
> Internet novice, that sent me a rant a few days ago:
>
>> Hi Henning,
>>
> We investigated the problem - turns out to be a case of mis- 
> handling non-standard port numbers and non-symmetric SIP requests.  
> We're well below BLISS complexity here - this is just a basic SIP  
> INVITE. These types of problems are not currently addressed in the  
> call flows or torture test documents, unfortunately.
>
> Henning
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Oct 2007 16:31:03 -0400

How do you want such examples documented?  Email? (presumably not in this email list... where?)
-hadriel

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, October 20, 2007 4:07 PM
> To: Hadriel Kaplan
> Cc: Richard Shockey; 'Cullen Jennings'; [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 23 Oct 2007 13:01:14 +0200

Cullen,

I share your thoughts.

> I really hope we can get the configuration framework and and 
> data model work completed.

'Configuration framework' is
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
12.txt? I see it's in 'AD is watching' state. What prevents it being
completed? 

What do you refer to when you say 'data model work'? 

Dan 
<individual hat and OPS mindset> 

> Sent: Monday, October 22, 2007 9:02 PM
> To: Henning Schulzrinne
> Cc: [email-masked]
> I have some similar frustrations to Phil. I actually think 
> that is more a problem with a lack of a usable configuration 
> framework and data model than anything to do with Digest 
> authentication. We have needed something in the configuration 
> space for a long time - even just common terminology on what 
> the various fields are called would be an improvement. I 
> really hope we can get the configuration framework and and 
> data model work completed.
> 
> > for what seems like the same field).
> >> And I still can't make it work. Voice flows in one 
> direction only.  
> >> I'm
> >> implemented and contributed to them. And if *I* can't 
> figure out how 
> >> to make this stuff work, how is the average grandmother 
> expected to 
> >> do so?
> > We investigated the problem - turns out to be a case of 
> mis- handling 
> > non-standard port numbers and non-symmetric SIP requests.
> >>>> SIP, and at least hundreds of independent deployments of non- 
> >>>> trivial scale. However, for some reasons SIP has not yet reached 
> >>>> the target state where one could just pick any User Agent and 
> >>>> succesfully use it with any SIP service provider on the 
> Internet, 
> >>>> as could be expected from any "true" Internet protocol.
> >>
> >> My experience with UA / SIP operators interworking isn't 
> that bad, at 
> >> least if compared to what I see when I try cross-provider 
> SIP calls.
> >>
> >> So: Is this BOF explicitly restricted to intra-provider 
> issues (UAs 
> >> talking to VoIP operators) or is it supposed to cover 
> inter-provider 
> >> calls as well?
> >>
> >> /ol
> >> --

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 23 Oct 2007 12:03:11 -0500

I'm not Cullen, but I'll answer the questions on the status of the
configuration framework, since I'm the shepherding chair.  This document
has completed its 3rd WGLC in June 2007 in  the SIPPING WG and an
updated version should be available this week.  You can check the charts
(it takes 3 slides just for the timeline) from IETF-69 to see the
history of this document in the WG:
http://www3.ietf.org/proceedings/07jul/slides/sipping-7/sld2.htm

The referenced data model work is the schema for the profile datasets
that provides the basis for the realization of the framework.  There is
an individual document (now expired) that needs to be progressed that
provides the baseline for the schema definitions:
http://tools.ietf.org/html/draft-petrie-sipping-profile-datasets-04
That document had been put on hold to complete the framework document.
The plan is to get that document updated (likely by a new editor) and
submitted for discussion prior to IETF-70.  

Regards,
Mary. 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2007 6:01 AM
To: Cullen Jennings; Henning Schulzrinne
Cc: [email-masked]
Subject: RE: [RAI] Fwd: SIPREAL BOF proposal for IETF 70

Cullen,

I share your thoughts.

> I really hope we can get the configuration framework and and data 
> model work completed.

Dan

> just common terminology on what the various fields are called would be

> an improvement. I really hope we can get the configuration framework 
> and and data model work completed.
>