Subject: [Sipping] Question regarding Redirect reason and SIP

From: [email-masked]
Date: Wed, 22 May 2002 10:15:31 -0600

Questions:
 
Are there any generally accepted methods (SIPPING Work) regarding the
passing of redirect reason information in SIP headers?  This is specific to
a voicemail scenario where the called party is on the internet and the call
is forwarded to an internet call waiting service thus the service needs to
known the reason for the forward.
 
Regards,
 
Jason Bach
Level 3 Communications
1025 Eldorado Blvd.
Broomfield CO 80021
Bus. (720) 888-2821
Mob. (720) 272-8698
mailto:7202728698 <mailto:[email-masked]> @mobile.att.net

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 22 May 2002 13:52:20 -0500

Jason asked:
----
Are there any generally accepted methods (SIPPING Work) regarding the
passing of redirect reason information in SIP headers?  This is specific
to a voicemail scenario where the called party is on the internet and
the call is forwarded to an internet call waiting service thus the
service needs to known the reason for the forward.
----

People keep trying to come up with this approach because it's the
obvious transformation from ISDN. 

Fortunately, SIP is significantly more expressive than ISDN, so there's
been a big push back against this rather naive approach.

There are really two alternatives:

1) Use a generic URI for "the user" and encode a new header for every
possible treatment that you might want to give the call. This requires
writing lots of new standardized extension specifications.

2) Have the URI include enough information so that the application can
decide appropriate treatment. See RFC 3087. This doesn't require writing
lots of new standardized extension specifications.

If one uses alternative 2, there are two reasonable approaches:

2A) Encode the functionality in the "user" part of the URI:
	sip:[email-masked]
      sip:[email-masked]

2B) encode the functionality in a URI parameter
      sip:[email-masked];why=hewasbusy
      
Then there's a separate question as to whether either sort of encoding
needs to be "standardized".

The good news is that the functionality is independent of the format,
and the world continues to work well in a mixed-use model. All that is
required is that the forwarding entity "know" what URL to retarget too
for each of the condition cases that it wishes to distinguish. Whether
this knowledge is provisioned or algorithmically generated is a problem
of local scope only.

--
Dean

_______________________________________________
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