Re: [Sip-implementors] 183 session

[Paul Kyzivat]

On 9/19/17 11:28 AM, Verma, Salil (Nokia - IN/Noida) wrote:

Hi ,

Please help me to understand the difference between 183 with SDP and without 
SDP.


A 183 without SDP has no role in the offer/answer process. It mostly 
just says "I'm working on your call." In the absence of the 100rel 
option it has no other significance. If it also has 100rel then it 
establishes an early dialog.



Is it really required to send 183 after invite r we can directly send 180 
ringing ? In which all condition we have to send 183


If you want to send 180 to indicate that you are alerting then there is 
no reason to also send 183. Just as with 183, the 180 may be sent with 
or without SDP.


Note that the decision about whether to play early media at the UAC is 
not determined by the reception of a 183. Rather it is governed by the 
reception of media at the port in your offer, and can in principle occur 
even without receiving a 18x of any sort. However some implementations 
refuse to play early media until they receive an answer with an IP and 
port that they use to verify the sender of the media. If you are doing 
such validation, then it shouldn't matter what sort of 18x it is.


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

[Sip-implementors] 183 session

[Verma, Salil (Nokia - IN/Noida)]

Hi ,

Please help me to understand the difference between 183 with SDP and without 
SDP.
Is it really required to send 183 after invite r we can directly send 180 
ringing ? In which all condition we have to send 183


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

Re: [Sip-implementors] SBC sending 403 Forbidden when UE includes Anonymous in From header's user part

[Paul Kyzivat]

On 9/19/17 6:39 AM, Abinash Sarangi wrote:

Hi Experts,

We are facing an issue wherein INVITE sent by UE is being rejected by SBC with 
403 Forbidden


This is a *policy* issue rather than a *protocol* issue.
The response indicates that the callee (or the SBC acting on behalf of 
the callee) has a *policy* leading it to reject the call.


In this case it seems likely that it doesn't want to accept calls where 
the caller is unknown. In environments that use PAI, the expectation is 
that calls will have a known verified caller identity. There may still 
be provision (Via Privacy and an anonymous From) to hide that identity 
from the callee, but the infrastructure insists on knowing.


If you want to place calls in this environment then you have to abide by 
the rules of identification put in place by the network. Again, this 
isn't a protocol issue.


Thanks,
Paul


INVITE snap

INVITE sip:0655430...@xyz.net;transport=TLS SIP/2.0
Via: SIP/2.0/TLS a.b.c.d:37789;branch=z9hG4bK-n5o538-e-125n6m9;rport
Max-Forwards: 70
To: 
From: Anonymous ;tag=n5o538-xwco1g
Call-ID: n5o538-1hjm5to-9@90-237-255-147
CSeq: 14 INVITE
Contact: 
Content-Type: application/sdp
Content-Length: 429
User-Agent: ABC 1.6.3 a

User itself is sending anonymous value in FROM header with no Privacy header 
and without P-Preferred-Identity


In IMS network, CLI information is extracted from PAI and if no PAI is present 
same information can be retrieved from “From” header.


From RFC 3261 point of view,


The From header field allows for a display name.  A UAC SHOULD use
the display name "Anonymous", along with a syntactically correct, but
otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
identity of the client is to remain hidden.

Question : should the UE also send Privacy header with appropriate values ?

Is the SBC behavior appropriate in rejecting the INVITE ?


Network deployment:

UE--> SBC--> IMS core --> MTAS



Thanks
AS
___
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