RE: [Sip] RE: Question to Identity draft

Kasturi = Narayanan, · But...

Udit,

Both methods of communicating more detail for the error condition
seem valid / ok to me.

It appears the main difference in their use is that
the Warning

header entries are mandated in 3261 and furthered by IANA registered ones.

The warning codes range for SIP is stated as being the 3xx block which
are

already divided up into categories, currently there seems limited scope
in

using this range (390 - 399 for miscellaneous).

3261 supports extending the default reason phrase
for responses and

gives some specific examples of this is advocated 261 gives examples of

doing this for specific responses (182, 400, 480). Advocating a standard

for the wording for common conditions like your examples below might be
a

good idea.

Regards - Wayne.

Udit asked:

*************************************************************

Hi,

I was just wondering that are there any ways to give
different indications

when user is not able to take the call.

There are error responses like 480, 486 used to indicate the busy

condition but still they are not able to indicate the exact failure

status.

However, there can be scenarios like:

i)   User rejects the call.

ii)  All lines are busy and user cant take the call.

iii) Ringing timeout occur: No Answer and more....

I feel there are possibilities of indicating to the
end user by using

error response status text, "Warning" header, or "Reason"
header.

Please let me know which is more standard approach followed.

Thanks,

Udit

_______________________________________________

Sip-implementors mailing list

Sip-implementors@cs.columbia.edu

http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

**********************************************************************

Any personal or sensitive information contained in this email and

attachments must be handled in accordance with the Victorian Information

Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988

(Commonwealth), as applicable.

This email, including all attachments, is confidential.
 If you are not the

intended recipient, you must not disclose, distribute, copy or use the

information contained in this email or attachments.  Any confidentiality
or

privilege is not waived or lost because this email has been sent to you
in

error.  If you have received it in error, please let us know by reply

email, delete it from your system and destroy any copies.

**********************************************************************

_______________________________________________

Sip-implementors mailing list

Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Udit,

Please excuse my ignorance but can you explain / point me to the
draft RFC that covers how this works ?. If you finish
the initial A to B

call, either party hanging up sends a BYE - the session and dialog will
end

OR did the initial call setup with pre-paid verification created a dialog

that exists beyond the A to B call | session (3PCC server is B2BUA or

something ?).

Assuming the scenario is valid a UAS can respond with
a 180 and I

would expect that it could be used to quench INVITE retransmissions and

trigger local ringback.

BUT..

In the scenario you describe below using 3PCC A is
being INVITEd to

setup up the new call leg between A and C, so it is the UAS for this

request. So, it will be be doing the responses - 1xx, 200 OK and therefore

it wont receive a 180 ringing at all for the effect you were looking for.

Regards - Wayne.

Udit asked:

*********************************

>I want to know what should be the behaviour of
UAC after receiving 180

>response when dialog is already in confirmed state.

>I think it should process it, is this behaviour mentioned anywhere
in RFC?

>

>

>This scenario can occur in prepaid calling card application where user
A

>first calls B, and after finsihing talking, he calls another user C
on the

>same call.

>To connect user C, we can send Re-invite to user A agent resulting
in call

>connected between A and C as per thirdparty call
control.

>

>But before the call is answered by user C, if 180 Ringing is send to
user

>agent A, it should play ringback as user need to hear the ringback
to know

>the status of the second call.

>

>-Udit

_______________________________________________

Sip-implementors mailing list

Sip-implementors@cs.columbia.edu

http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

**********************************************************************

Any personal or sensitive information contained in this email and

attachments must be handled in accordance with the Victorian Information

Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988

(Commonwealth), as applicable.

This email, including all attachments, is confidential.
 If you are not the

intended recipient, you must not disclose, distribute, copy or use the

information contained in this email or attachments.  Any confidentiality
or

privilege is not waived or lost because this email has been sent to you
in

error.  If you have received it in error, please let us know by reply

email, delete it from your system and destroy any copies.

**********************************************************************

Udit,

Both methods of communicating more detail for the error condition
seem valid / ok to me.

It appears the main difference in their use is that
the Warning

header entries are mandated in 3261 and furthered by IANA registered ones.

The warning codes range for SIP is stated as being the 3xx block which
are

already divided up into categories, currently there seems limited scope
in

using this range (390 - 399 for miscellaneous).

3261 supports extending the default reason phrase
for responses and

gives some specific examples of this is advocated 261 gives examples of

doing this for specific responses (182, 400, 480). Advocating a standard

for the wording for common conditions like your examples below might be
a

good idea.

Regards - Wayne.

Udit asked:

*************************************************************

Hi,

I was just wondering that are there any ways to give
different indications

when user is not able to take the call.

There are error responses like 480, 486 used to indicate the busy

condition but still they are not able to indicate the exact failure

status.

However, there can be scenarios like:

i)   User rejects the call.

ii)  All lines are busy and user cant take the call.

iii) Ringing timeout occur: No Answer and more....

I feel there are possibilities of indicating to the
end user by using

error response status text, "Warning" header, or "Reason"
header.

Please let me know which is more standard approach followed.

Thanks,

Udit

_______________________________________________

Sip-implementors mailing list

Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
  =
“state: This attribute indicates whether the =
document contains the
      full dialog =
information, or whether it contains only =
information
      on those =
dialogs which have changed since the previous =
document
      (partial). =
“

From this it looks that the =
“state” attribute is partial or full depending upon if =
“some” or “all” dialogs are reported in the =
NOTIFY. The semantics of partial or full do not convey any information =
on the completeness of information within a <dialog> element (in =
context of any filter that subscriber may have set). =

This needs to be clarified =
in the spec: Should the implementer flush and rewrite the =
“row” with that dialog ID even when the dialog-info element =
indicates “partial” (which would imply that information =
within the <dialog> element is always complete for subsequent =
NOTIFY’s) or should it do equivalent of SQL update with whatever =
information is available within the dialog element. (In this latter case =
is there a need for equivalent of “full” in context of an =
individual dialog update). 

2>  Section =
4.1.4
 =
“4.1.4  Replaces

   The replaces element is used to =
correlate a new dialog with one =
it
   replaced as a result of an =
invitation with a Replaces header.  =
This
   element is present in the =
replacement dialog only (the newer =
dialog)
   and contains attributes with the =
call-id, local-tag, and =
remote-tag
   of the replaced =
dialog.

   <replaces =
call-id=3D"hg287s98s89"
       &nbs=
p;     local-tag=3D"6762h7" =
remote-tag=3D"09278hsb"/>” 
IMHO instead of call-id, =
local-tag and remote-tag the dialogID is necessary and sufficient =
information in the replaces element. The Subscriber may not be =
authorized to get this “replaced” dialog information like =
call-id etc.based upon some authorization policy. By giving away the =
dialog information of the replaced dialog the subscriber can gain =
information it was not privy of originally. However, if the subscriber =
was getting notifications for the replaced dialog also then it can use =
the dialogID to correlate. (Besides the subscriber table will most =
likely be keyed on dialogID. and =
user.)

3>  Section 4.1.5 =
“Referre=
d-By [11] header and contains the (optional) display =
name
   attribute and the Referred-By =
URI as its value.

   <referred-by =
display=3D"Bob">sip:bob@example.com</referred-by>̶=
1;

There could be identity =
concerns in sending out the referred-by information. Though not directly =
concerned with this draft, it could be mentioned about the mechanism to =
expunge the referer information based on privacy headers. The same =
applies to other identity elements also. =

4> Section 4.3 =
Perhaps it could be added =
that the dialog information table as suggested is referenced by the =
SUBSCRIBE/NOTIFY dialog (that which subscriber maintains with the =
notifier) AND the user whose dialog information is retrieved, this will =
help to associate the incremental status updates that each NOTIFY =
entails. In the absence of any such association there could be a =
problem: Let us say that there were two dialogs that were being reported =
about, one dialog gets terminated and UA sends a NOTIFY with a higher =
“version” (+1) attribute. If this NOTIFY is lost and =
subsequently another NOTIFY with yet higher (+2) version attribute is =
sent then this SHOULD result in refresh request from Subscriber (sec =
4.3). The Notifier will then generate a “full” notification =
but it will potentially NOT have any information on the =
“terminated” dialog. The Subscriber now needs a higher level =
reference to the DialogID that it can use to now flush the now =
terminated dialog. 
This probably is implied in =
the text but IMO may help implementers if specified clearly. =

5> Should target =
refreshes be reported, i.e. have a new “event” type in =
schema for state element <xs:enumeration =
value=3D"refreshed"/> for target refreshes? =

6> Section 6.1 Minor =
typo - 
“If it =
receives a second 180 with a different tag:

------- =
SIP/2.0 180 Ringing

   This results in the creation of =
a second dialog:

   <?xml =
version=3D"1.0"?>
   <dialog-info =
xmlns=3D"urn:ietf:params:xml:ns:dialog-info"<=
/font>
       &nbs=
p;        =
version=3D"2"
       &nbs=
p;        =
state=3D"full"
       &nbs=
p;        =
entity=3D"sip:alice@example.com">     <dialog =
id=3D"as7d900as8" =
call-id=3D"a84b4c76e66710"<=
font
size=3D2 face=3D"Courier New">       &nbs=
p;     local-tag=3D"1928301774" =
remote-tag=3D"456887766"
       &nbs=
p;     =
direction=3D"initiator">
=
       =
<state>early</state>
     =
</dialog>
     <dialog =
id=3D"as7d900as8" =
call-id=3D"a84b4c76e66710"
<=
font
size=3D2 face=3D"Courier New">       &nbs=
p;     local-tag=3D"1928301774" =
remote-tag=3D"hh76a"
       &nbs=
p;     =
direction=3D"initiator">
=
       =
<state>early</state>
     =
</dialog>
   </dialog-info> =
“

The dialog id in the second =
dialog created should have a different dialogID as specified in section =
4.1

7> The draft talks about =
the dialog events at the UAs because this is where the dialog state =
machine exists, but will it be useful to have the capability to monitor =
such dialogs at a record routing proxy?  So will it be useful to =
enable a Subscriber SUBSCRIBE to a dialog which is “known” =
at  a proxy? 

8> This draft more than =
other event drafts points towards a need for a mechanism in which a =
subscription would be required through a non SUBSCRIBE mechanism. This =
is because the Subscriber in this case may be a party outside of the =
dialog that needs to monitor and may not know when the dialog came into =
existence. Of course the subscriber can subscribe before hand, but will =
still lack the capability to subscribe in real-time to a dialog to which =
the subscriber may be interested in. =
Will it be worthwhile to =
add a mechanism by which the subscriptions could also carry over another =
method like INVITE? 
A new =
“Subscription” header could carry the subscription and the =
value of the header may be the target for the subsequent NOTIFY. This =
could be a non- SUBSCRIBE way of installing subscription. The Event =
header would then have the required event package. =

If the subscriber is within =
the trust domain then the NOTIFY’s could start as soon as the =
first qualifying event occurs rather than waiting for SUBSCRIBE or =
relying on before-hand subscriptions. =

This feature could be =
useful for future event users like say an event package for notifying =
the Voice XML media server interaction state after dialog establishment =
[e.g. notifications about the digit collection etc. rather than using =
HTTP route]. 

In a nutshell this would be =
useful to a subscriber who cannot know before hand where/whom to =
subscribe for the events that it is interested in as the dynamic network =
situations create these event conditions. So the =
“application” (say a proxy) that knows about the Subscriber =
and this special condition occurring in the network, inserts this =
Subscription header and Event header with the subscribers target =
address.  
If Notifier wants to =
authenticate the subscriber it could generate a NOTIFY with =
Subscription-State as “terminated” and =
reason=3Dauth-required.

Regards =
Nasir =
Khan
BEA Systems, Inc. =

> From: Udit_Goyal@3com.com

>

> Consider the following prepaid card application scenario::

>

> Assuming party A and B are talking and following steps occur:

> i)   Party B hung up.

> ii)  B2BUA end the dialog with user B and connect user A to

> media server

> using REINVITE asking for another number.

> iii) After A presses the digits, B2BUA initiates a new dialog

> for user C

> iv) When party C is ringing,  B2BUA sends 180 Ringing to agent
A.

IMHO, the fundamental problem is that your call flow
maintains one dialog

between A and the B2BUA, but you want to reflect back to A all the call

progress indications (provisional responses) from the dialogs between B2BUA

and B, C, etc.

To avoid this, perhaps the B2BUA could issue INVITE
with Replaces: to A to

"reinitialize" the dialog state with A.  (In reality, replace
the previous

dialog with a new one.)

>

>

>     User A              B2BUA
              User B

> Media Server

>       |              
    |(1) BYE            |  
                |

>       |              
    |<------------------|          
        |

>       |              
    |(2) 200            |  
                |

>       |              
    |------------------>|          
        |

|  INV with Replaces|

|<------------------|

|  BYE of dialog 1  |

|------------------>|

|  200 of dialog 2  |

|------------------>|
OK, I'm too lazy to draw the entire message flow.
 But it seems like you

could generate suitable INVITEs with Replaces and/or REFER messages to
cause

A to drop the dialog with B, establish a new one with the media server,
then

drop that dialog and replace it with one to C, etc.  Since each is
a new

dialog, A's UA will receive and display correctly any call progress

indications.

This is also more in line with the architecture envisioned
in RFC 3261.

Instead of having a B2BUA, you might be able to just use a proxy that keeps

itself in the signaling path with a Record-Route.

Dale

_______________________________________________

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP Protocol

Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application
of sip