RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

["Elwell, John" <[e-mail]>]

Dean,


> -----Original Message-----
> From: Dean Willis [mailto:[e-mail]] 
> Sent: 12 October 2005 20:04
> To: Paul Kyzivat
> Cc: Michael Hammer (mhammer); sipping; Elwell, John
> Subject: Re: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 
> >
> > I think that describes at least part of the problem. The sip  
> > network can have MANY more states - too many to enumerate. For  
> > instance:
> >
> > - one UA is set to DND and will refuse all calls
> > - one UA is on a voice call and will refuse all other calls
> >   until that is over. Then it will accept calls that include
> >   voice, accepting the voice and refusing other media
> > - one UA is in an IM session and a voice session. It will
> >   accept other incoming sessions involving IM. If an offer
> >   is for IM and voice it will accept the IM and refuse the
> >   voice. If it is for voice only it will refuse it. When
> >   the voice call is over the situation will change.
> >
> > Now, an incoming voice call arrives. It is refused by all the  
> > available UAs and then is diverted to voicemail. What is 
> the reason  
> > for the diversion? If you have an answer, then how would 
> the system  
> > arrive at that answer.
> >
> The INVITE request was proxied to voice mail because no contact was  
> accepted.
> 
> One could either model this as four "history" operations or as one.  
> Personally, I like doing it as one, but other people have proposed  
> cases that need the other detail.
> 
> The logic looks something like:
> 
> contact-routing PROXY-PARALLEL to sip:contact-1, response=486
> contact-routing PROXY-PARALLEL to sip:contact 2, response=486
> contact-routing PROXY-PARALLEL to sip:contact 3, response=486
> busy-or-no-answer-trigger PROXY-SEQUENTIAL to sip:voicemailURI,  
> response=200
> 
> Can we express that in H-I?
> 
> --
> Dean
>
[JRE] Yes, I believe that can be expressed in History-Info. Probably the
proxy would consider only the last one as a service retarget, so would do
the actions prescribed in the service-retargeting draft only on the last
one, where the old-target would be the original AoR and the reason would
probably be busy (since there were suitable contacts registered but they
were all suitable contacts were busy at this time).

John

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