Subject: RE: [Sipping] Opening a discussion on Multiple Path Retry

From: "Attila Sipos" <[email-masked]>
Date: Mon, 19 Nov 2007 11:54:42 -0000

I agree with Dale that this MPR problem has to be solved.

And I agree with Sreeram, the new information has to be in
a new header or possibly new headers.

The response codes tell you why the request failed,
so they should be left to convey that information.

To convey something different (did the call get to a UA?
or where did the call get to?), we need a new header(or headers).

(Also people mentioned how to determine how far the request went.
 For this, we already have request history information:
 http://www.ietf.org/rfc/rfc4244.txt )

Regards,

Attila

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 19 November 2007 10:09
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:[Sipping] Opening a discussion on Multiple Path Retry

Hi Dale,

I think this is a very good topic which needs discussion.

A proxy is considered to be a constitute of UAC and UAS, so it is very
difficult to distinguish the exsisting Response codes received are from
a proxy or the end UA.

We cannot tell in a network, whether the response comes from the end UA
or not.
Example in a case of interworking ua1-sip1-isup-sip2-ua2:
When ua1 receives a response(4xx), we cannot tell if it is from end UA,
because end UA is some where down the line And sip2 can also be reached
via different path.

Based on the exsisting implentations already in place, I feel creating
more response codes is more burden.
So instead we can create a new header:(like)Enitysource.
This will be inserted in all the resposne codes. This will have the
values UA/Proxy/token.
Based on that we can have the behaviour on the originating UA.

Example: 480. this response will have : Enitysource: Proxy which
indicates that proxy have added this response.

SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/TLS
ss1.example.com:5061;branch=z9hG4bK83749.2;received=192.0.2.54
Via: SIP/2.0/TLS
client.atlanta.example.com:5061;branch=z9hG4bK74bf9;received=192.0.2.103
From: Alice <sips:[email-masked]>;tag=1234567
To: Bob <sips:[email-masked]>;tag=314756
Call-ID: [email-masked]
CSeq: 1 INVITE
Enitysource: Proxy
Content-Length: 0

>>The problem is, SIP doesn't make it particularly clear whether a call 
>>failed due to some difficulty with transport vs. the call reached the
UA and was actively or passively rejected.
I feel always difficulty with transport gives 408.

I have seen similar problem in the network because the proxy is not
avilable and the calls are failed.
The possible reasons for the call to fail are : Proxy is down,2)
rebooted 3) proxy is overloaded so not accepting new messages.
So I had proposed a Draft for asynchronous service change (fyi)
http://rfc.netvolante.jp/internet-drafts/draft-sreeram-specify-method-00
.txt

Regards,
Sreeram
----
Sreeram Kanumuri
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2007 9:04 AM
To: [email-masked]
Subject: [Sipping] Opening a discussion on Multiple Path Retry

In my employer's PBX system, we're starting to consider problems that
show up when there are multiple ways of getting a call to the
destination, and we want the PBX to try alternatives only if the first
attempt failed.  The problem is, SIP doesn't make it particularly clear
whether a call failed due to some difficulty with transport vs. the call
reached the UA and was actively or passively rejected.

I've written an I-D to start the discussion of solutions to this
problem:

http://www.ietf.org/internet-drafts/draft-worley-redundancy-response-02.
txt

A new version of I-D, draft-worley-redundancy-response-02.txt has been
successfuly submitted by Dale Worley and posted to the IETF repository.

Filename:        draft-worley-redundancy-response
Revision:        02
Title:           Supporting Multiple Path Routing in the Session
Initiation Protocol (SIP)
Creation_date:   2007-11-18
WG ID:           Independent Submission
Number_of_pages: 9

Abstract:
An increasing number of SIP architectures implement multiple path
routing (MPR), which is the providing of more than one path for a call
to reach a destination user agent (UA).  To implement MPR well, the
proxy which forks a request onto the redundant paths needs to be able to
determine if a fork that failed reached the destination UA and was
rejected by the UA (and so an alternate path should not be tried), or if
the fork failed before reaching the UA (and so an alternate path should
be attempted).  This document is to begin a discussion of strategies for
making this determination.

Dale

_______________________________________________
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

_______________________________________________
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: jagmohan chauhan <[email-masked]>
Date: Tue, 20 Nov 2007 17:02:37 +0530

Hi all
I have certain queries: How are we going to determmine the mpr set 
initially.
Also suppose we have 2 uri for a partcular user .we tried for first uri 
and we got a 4xx response while trying that call.Now we come to know 
somehow that the error was due to transport failure and then we want to 
try  to esatbalish the call. Now the queery is will we try on same uri 
through a  different route or we will try second uri. Also how we are 
going to determine the best route for a call establishment every time a 
call fails due to transport failure.

Regards
Jagmohan Chauhan

"Attila Sipos" <[email-masked]> 
11/19/2007 05:24 PM

To
<[email-masked]>, <[email-masked]>
cc
[email-masked], [email-masked]
Subject
RE: [Sipping]  Opening a discussion on Multiple Path Retry

Regards,

Attila

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 19 November 2007 10:09
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re:[Sipping] Opening a discussion on Multiple Path Retry

Hi Dale,

Regards,
Sreeram
----
Sreeram Kanumuri
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 19, 2007 9:04 AM
To: [email-masked]
Subject: [Sipping] Opening a discussion on Multiple Path Retry

Abstract:

Dale

***********************  Aricent- Confidential   ***********************
"DISCLAIMER: This message is proprietary to Aricent  and is intended solely for the use of 
the individual to whom it is addressed. It may contain privileged or confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you have received this message in error, 
please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________
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: [email-masked]
Date: Tue, 27 Nov 2007 16:49:22 -0500

From: jagmohan chauhan <[email-masked]>

For the time being, I am assuming that this information is configured
into the proxy that is doing the forking.

Dale

---

From: "Vijay Tiwari" <[email-masked]>
Date: Wed, 28 Nov 2007 08:18:08 +0530

we are have two kind of forking server

1. first is parallel forking
2. second one is serial forking

so u can try with serial forking. suppose first UA is not rechable then its
going to the second UA uri.

thanks
vijay

---

From: jagmohan chauhan <[email-masked]>
Date: Wed, 28 Nov 2007 08:59:42 +0530

Hi 
It is OK that mpr related info. can be configured in proxy itself 
initially. But how are we going to configure such info. Will we use record 
route or anything else. Also how many paths are we going to put in a n mpr 
set. If suppose we have 100 paths to a particular UA then we need to 
maintain all the paths or a few chosen one's and how are we going to 
determine which path's are to be retained out of the 100 we got. 

Regards
Jagmohan Chauhan 

[email-masked] 
11/28/2007 03:19 AM

To
[email-masked]
cc

Subject
Re: [Sipping]  Opening a discussion on Multiple Path Retry

Dale