[Sip-implementors] Cause Code in the 500 Server Internal Error message

[David Mathe (DS)]

Good Day.

Is it acceptable for a switch to send the cause code as a Reason in the 500 
Server Internal Error Message instead of sending the Cause code on its own to 
the caller in a SIP voice call? Example below

[cid:image002.png@01D15FE5.4EB417F0]

Thank You and Warmest Regards
David  Mathe






~~
This e-mail is subject to the Telkom SA SOC Ltd electronic communication legal 
notice,
available at : http://www.telkom.co.za/TelkomEMailLegalNotice.PDF 

~~
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] P-Access-Network-Info Header

[Basu Chikkalli]

Hi,

Does P-Access-Network-Info Header received in INVITE should be validated?

RFC-7315:

  P-Access-Network-Info  = "P-Access-Network-Info" HCOLON
access-net-spec *(COMMA access-net-spec)
  access-net-spec= (access-type / access-class)



Should we consider P-Access-Network-Info Header only if
access-type/access-class matches with predefined Node's (IMS AS) ones.


Thanks

Basaw
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] RE-INVITE QUESTION

[Roman Romenskyi]

Hello,

 If anyone have an idea:
UAC sends RE-INVITE, than send CANCEL request, is this situation is
correct? Because dialog state is connected, and 200 OK for a first
INVITE are sent.
How We should process it? Please point me to rfc.

Best regards, Roman.
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RE-INVITE QUESTION

[Anand Konji]

Hi,

Following info might help you,

Refer rfc 6141 section 3.8,

*3.8* *. Clarifications on
Canceling Re-INVITEs*

Section 9.2 of RFC 3261  [
RFC3261 ] specifies the behavior of a
UAS responding to a CANCEL request. Such a UAS responds to the INVITE
request with a 487 (Request Terminated) at the SHOULD level. Per the rules
specified in Section 3.3 ,
if the INVITE request was a re-INVITE and some of its requested changes had
already been executed, the UAS would return a 2xx response instead.

Regards,
Anand
On Feb 4, 2016 9:41 PM, "Roman Romenskyi"  wrote:

> Hello,
>
>  If anyone have an idea:
> UAC sends RE-INVITE, than send CANCEL request, is this situation is
> correct? Because dialog state is connected, and 200 OK for a first
> INVITE are sent.
> How We should process it? Please point me to rfc.
>
> Best regards, Roman.
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] RE-INVITE QUESTION

[Paul Kyzivat]

On 2/4/16 11:11 AM, Roman Romenskyi wrote:

Hello,

  If anyone have an idea:
UAC sends RE-INVITE, than send CANCEL request, is this situation is
correct? Because dialog state is connected, and 200 OK for a first
INVITE are sent.
How We should process it? Please point me to rfc.


CANCEL has nothing to do with dialogs, only with transactions. So the 
fact that the reinvite is within a dialog has no bearing on the question.


(Or are you concerned about the use of the 481 response to CANCEL. Note 
that 481 has two distinct meanings: for CANCEL it means there is no 
matching *transaction*. Other things it means there is no matching 
*dialog*. For CANCEL 481 *does not* say anything about the dialog.)


Note that you can *never* be sure when you send a CANCEL that it will be 
received in time to be effective. It is always possible that the request 
was already processed before the CANCEL was handled. For the recipient, 
handling CANCEL should typically be on a best-effort basis. (But you 
won't find that in the spec.) You aren't *obligated* to expedite it 
through your request processing.


Note that CANCEL is more likely to be effective on an initial INVITE, 
because the invite is likely to pause for alerting, giving time to 
process a CANCEL. A reinvite is likely to be much quicker, and perhaps 
to be processed synchronously, so that there is little opportunity to 
notice a CANCEL. Also, as specified in section 9.1 of 3261, the CANCEL 
can't be sent until a provisional response has been received, nor after 
a final response has been received.


I find that section 9 of 3261 is pretty clear. What are you confused 
about? Note that there is a clarification on cancelling reinvite in 
RFC6141, but I don't think it is pertinent to this discussion.


Thanks,
Paul



___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors