Subject: RE: [Sipping] Redirection on busy and History Info

From: "Elwell, John" <[email-masked]>
Date: Tue, 01 Nov 2005 07:45:04 +0000

As co-author of both the redirection-reason draft and the
service-retargeting draft, my motivation was essentially providing a model
that described what has happened so far, rather than a model that prescribes
what should happen next. The redirection-reason draft clearly follows the
first model. The service-retargeting draft could support either model, which
is one of its advantages. So I guess the question is whether we need support
for both models and whether it is appropriate to have a single solution to
satisfy both models or more appropriate to have two separate solutions.

Concerning the "what has happened so far" model, this should extend to being
interoperable with PSTN. Given that History-Info is a basis for both/all the
solutions proposed so far (even service-retargeting relies on History-Info
to capture what happened prior to the last retarget), then History-Info will
play some part in this PSTN interoperability.

John

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 01 November 2005 00:51
> To: Gonzalo Camarillo; Mary Barnes
> Cc: sipping; Elwell, John
> Subject: RE: [Sipping] Redirection on busy and History Info
> 
> Also, on the "what has happened so far" model, one issue is PSTN
> interop.
> 
> I always held the view that SIP UAC or proxies should not 
> generate "fake" History-Info to account for redirection that
> occured outside of SIP (e.g., the PSTN). I.e.., it shouldn't
> lie that that there was a 486 or 302 received when there 
> were no such thing.
> 
> This is one of the main reason for the 3087 model.
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> > Sent: Monday, October 31, 2005 10:58
> > To: Barnes, Mary [NGC:B601:EXCH]
> > Cc: sipping; Elwell, John
> > Subject: Re: [Sipping] Redirection on busy and History Info
> > 
> > 
> > Hi,
> > 
> >  > Of course,  I think the primary debate isn't necessarily over
> > > whether one could or could not use History-Info for this type of 
> > > service, but rather there is a preference to provide even more 
> > > explicit service information, per the RFC 3087 model.
> > 
> > as Dave pointed out a few messages ago in a related thread, 
> there are 
> > two models: one where the entity explains what has happened 
> > so far, and 
> > the other where the entity tells what should happen in the 
> > future. The 
> > solution we are discussing here would cover the former model. 
> > As long as 
> > there are folks interested in that model, I guess it is worthwhile 
> > pursuing that solution (or something equivalent).
> > 
> > Then, as a separate discussion, we can analyze how to support 
> > the latter 
> > model as well.
> > 
> > Cheers,
> > 
> > Gonzalo
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current 
> > sip Use [email-masked] for new developments of core SIP
> > 
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 01 Nov 2005 09:52:08 +0200

Hi Francois,

a UAS stating that there was a 486 response and then a 302, when all it 
did was redirecting because the user was busy (i.e., there was no 486 
response in the network) is not actually cheating, IMO. It is just 
modeling itself as two SIP entities (a virtual proxy and a UAS) with a 
SIP interface between them.

We have a similar case with the double routing mechanism described in 
RFC 3486 used with Sigcomp, where a proxy record-routes twice. It is not 
cheating; it is just modeling itself as two proxies linked by a SIP 
interface.

Cheers,

Gonzalo

Francois Audet wrote:
>>as Dave pointed out a few messages ago in a related thread, there are 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Nov 2005 17:32:02 -0600

What about addresses?

A PSTN gateway will only obviously understand addresses that are a phone
number.

If I call sip:[email-masked] and your wish to forward to voicemail,
you have not only to "fake" the busy 486 and embed it in 302, but you'll
also have to substitute a phone number to an email-like address.

All this makes the History-Info is custom-tailored for the application
(in this case, voicemail). 

It puts a big burden on the proxy to "know" all this as it effectively
has
to create different History-Info formats for different applications, or,
even more sinister, it has to "dumb-down" the History-Info to "look"
like a PSTN redirect number (even if that is not what was dialled in the
first place).

And finally, it won't work with a redirect server.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, November 01, 2005 11:55
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: Gonzalo Camarillo; Elwell, John; sipping; Barnes, Mary 
> [RICH2:B601:EXCH]
> IMO "fake" reason codes are quite acceptable as long as they 
> convey the 
> proper semantics. Busy is busy, whether it came from a UA, proxy, or 
> gateway.
> 
> If "fake" reason codes are not acceptable, then gateways 
> should always 
> be returning pstn codes rather than sip codes.
> 
> 	Paul
> 
> Francois Audet wrote:
> > I think it is a slippery slope.
> > 
> > A typical "IP PBX" (i.e., a big blob controling IP Phones and TDM
> > phones) or a Gateway can
> > often redirect "internally".
> > 
> > In this model, it would then generate "fake" History-Info 
> with 486 and 
> > other codes.
> > 
> > If I am the only one uncomfortable with this, then we *could* just 
> > write guidelines on rules for mapping History-Info to PSTN.
> > 
> > But again, this seems very bizarre to me...
> > 
> > I'd like to hear other opinions on this.
> > 
> > 
> >>From: Gonzalo Camarillo [mailto:[email-masked]]
> >>Sent: Monday, October 31, 2005 23:52
> >>To: Audet, Francois [SC100:9T51:EXCH]
> >>Cc: Barnes, Mary [RICH2:B601:EXCH]; sipping; Elwell, John
> >>>I always held the view that SIP UAC or proxies should not generate 
> >>>"fake" History-Info to account for redirection that 
> occured outside 
> >>>of SIP (e.g., the PSTN). I.e.., it shouldn't lie that that 
> there was 
> >>>a 486 or 302 received when there were no such thing.
> >>>
> >>>>Then, as a separate discussion, we can analyze how to support the 
> >>>>latter model as well.
> >>>>
> >>>>Cheers,
> >>>>
> >>>>Gonzalo
> >>>>
> >>>>Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >>>>This list is for NEW development of the application of SIP Use
> >>>>[email-masked] for questions on current sip Use 
> >>>>[email-masked] for new developments of core SIP
> >>>>
> >>>>
> >>
> >>-- 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
>

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Tue, 1 Nov 2005 20:53:26 -0600

I live the lie that vendors interoperate....

My MFGDLDIIO is that history-info with service retargeting URI provides
an interop. solution.

If this is not what in the best interest of the industry. please inform
me

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Dean Willis
> Sent: Tuesday, November 01, 2005 6:46 PM
> To: Francois Audet
> Cc: Elwell, John; sipping; Gonzalo Camarillo; Mary Barnes
> On Nov 1, 2005, at 5:33 PM, Francois Audet wrote:
> 
> >
> >
> >> [mailto:[email-masked]] On Behalf Of Dean Willis
> >> Sent: Tuesday, November 01, 2005 15:26
> >> Cc: sipping; Elwell, John; Gonzalo Camarillo; Barnes, Mary
> >> [RICH2:B601:EXCH]
> >> Why not fake some history-infos, as long as the result is a valid
> >> model of the internal process?
> >
> > Presumably, there was a reason why we designed History-Info 
> to reflect
> > what happened in SIP...
> >
> > What if you actually really wanted to know what happened? 
> (As opposed
> > to what service you want)?
> >
> 
> I'm reminded of that movie line" You want the truth? You 
> can't handle  
> the truth!"
> 
> History-info doesn't really tell us what happened -- it gives us an  
> abstraction of what happened that can be (relatively) concisely  
> described in SIP. If that abstraction provides adequate information  
> for building the specific services in question, do we need more? (We  
> may -- what other services do we think we might need to build?).
> 
> If you take the example far enough (and are willing to badly  
> paraphrase Wolfram) "the whole truth" would apparently 
> require having  
> had someone OUTSIDE the universe attach a hardware-assisted trace  
> module onto the universe and log everything from the Big Bang  
> forward. It would give us more state information than we're prepared  
> to deal with.
> 
> It's fair  to question whether all information that can be contained  
> in a H-I can be mapped to PSTN signaling. Of course it can't -- the  
> two dialects have different expressive ranges.  One can't "say" SIP  
> URLs in PSTN-speak. But if we have a consistent mapping of cause  
> codes, does that gives us enough to work with?
> 
> --
> Dean
> 
> 
> 
>