headers
Kumar, Hemanth | 4 Jan 2012 16:09
Favicon

Expected behavior for an INVITE sent without an offer

Hi,

What should be the behavior of UAC when an INVITE is sent without offer and Require 100rel and it receives
non-reliable/reliable 18x response without SDP?

Should the transaction be terminated by sending CANCEL?

The same scenario was given as comment which has not been addressed in  offer/answer draft-ietf-sipping-sip-offeranswer-03

http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-sip-offeranswer-03-seth.txt

" 3.    Section 1.1 :
   Comment :- We should define the behavior for a UAC which sends out an
INVITE without SDP and receives the first non-failure reliable response
without an Offer, due to the UAS not conforming to the draft. As this
being an open point can lead to multiple different implementations. Does
the UAC clear the call or send a PRACK and wait for the offer in
subsequent reliable responses."
Permalink | Reply | 21 comments |
headers
Kumar, Hemanth | 6 Jan 2012 09:22
Favicon

Re: Expected UAC behavior when a reliable/non-reliable 18x without SDP is recieved for an INVITE sent without an offer and require 100 rel

Hi All,

This is a B2BUA scenario.

This issue is as shown below

  UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA ------- INVITE [no SDP, Require:100 Rel]
-----------> UE2
                                                           B2BUA <------- 183 [no SDP] ------------- UE2
When an INVITE is sent with require 100rel and without an offer, misbehaving UE2 sends 18x without SDP.
RFC 6337 does not define the behavior of UAC in this case.

There could be 2 possible solutions:

1. Tear down the call by sending CANCEL on egress leg and 420 Bad extension response on ingress leg as shown below

  UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA------- INVITE [no SDP, Require:100 Rel]
-----------> UE2
  UE1 <----- 420 Bad extension ------------------------------   B2BUA<------- 183 [no SDP]
----------------------------------    UE2
                                                                                        B2BUA ------- CANCEL ------------------------------------------> UE2

2. Ignore 18x received and wait for reliable response containing SDP on the egress leg. On receiving the
response, send 18x reliably with SDP followed by 200 OK with the same SDP on the ingress leg. This ensures
backward compatability.

  UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA ------- INVITE [no SDP, Require:100 Rel]
-----------> UE2
                                                           B2BUA <---------- 183 [no SDP] ----------------------------------    UE2
  UE1 <----- 183 [with SDP] ---------------------------------    B2BUA <-----------   200 [with SDP]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Kyzivat | 6 Jan 2012 19:32
Picon
Favicon

Re: Expected UAC behavior when a reliable/non-reliable 18x without SDP is recieved for an INVITE sent without an offer and require 100 rel

UE2 is operating in a non-conforming manner.

In this (and most) cases, the behavior when dealing with a 
non-conforming message is not defined. Its up to you to decide what you 
want to do. You can experiment with what works best for you. There is no 
guarantee that anything you do will work *well*, or in a consistent way.

The main thing you should do is contact the vendor of the offending 
device, and ask them to fix their device.

	Thanks,
	Paul

On 1/6/12 3:22 AM, Kumar, Hemanth wrote:
> Hi All,
> This is a B2BUA scenario.
> This issue is as shown below
> UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA -------
> INVITE [no SDP, Require:100 Rel] -----------> UE2
> B2BUA *<------- 183 [no SDP] ------------- UE2 *
> When an INVITE is sent with require 100rel and without an offer,
> misbehaving UE2 sends 18x without SDP.
> RFC 6337 does not define the behavior of UAC in this case.
> There could be 2 possible solutions:
> 1. Tear down the call by sending CANCEL on egress leg and 420 Bad
> extension response on ingress leg as shown below
> UE1 ----- INVITE [no SDP, Require:100 Rel] ------------ > B2BUA-------
> INVITE [no SDP, Require:100 Rel] -----------> UE2
> UE1 <----- 420 Bad extension ------------------------------
> B2BUA<------- 183 [no SDP] ---------------------------------- UE2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sairam POKKUNURI | 9 Jan 2012 05:52
Favicon

Re: Expected behavior for an INVITE sent without an offer

 Hi

Invite without SDP is initiation of late media.
In that case 18x response can have a complete offer or 200 OK can have an
offer with ack containing answer.
More details are mentioned in RFC 3264 and 3261

Reg
Sai

On Wed, Jan 4, 2012 at 8:39 PM, Kumar, Hemanth <hkumar <at> sonusnet.com> wrote:

> Hi,
>
> What should be the behavior of UAC when an INVITE is sent without offer
> and Require 100rel and it receives non-reliable/reliable 18x response
> without SDP?
>
> Should the transaction be terminated by sending CANCEL?
>
> The same scenario was given as comment which has not been addressed in
>  offer/answer draft-ietf-sipping-sip-offeranswer-03
>
>
> http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-sipping-sip-offeranswer-03-seth.txt
>
> " 3.    Section 1.1 :
>   Comment :- We should define the behavior for a UAC which sends out an
> INVITE without SDP and receives the first non-failure reliable response
> without an Offer, due to the UAS not conforming to the draft. As this
(Continue reading)

Permalink | Reply | 16 comments |
headers
Vikas Jayaprakash | 9 Jan 2012 15:47
Picon

UE with Refer With Separate REPLACE header

Hi All,

In case of Attended Call transfer using *SIP REFER* (with *Replaces*),
there could be embedded replaces header in Refer-To or a separate
*Replaces*header.

Kapanga softphone and SJ phone sends embedded replaces header in Refer-To.

Is there any *UE* which sends *REFER* message with separate Replaces header?

Kindly let me know if you are aware of any such UE apart from Sipp.

Regards,
Vikas Jayaprakash
Permalink | Reply | 1 comment |
headers
Worley, Dale R (Dale | 9 Jan 2012 17:33
Favicon

Re: UE with Refer With Separate REPLACE header

> From: Vikas Jayaprakash [vikas.jayaprakash <at> gmail.com]
> 
> In case of Attended Call transfer using *SIP REFER* (with *Replaces*),
> there could be embedded replaces header in Refer-To or a separate
> *Replaces*header.

That is not correct.  The INVITE generated due to the REFER must have
a separate Replaces header, but the REFER may not have a separate
Replaces header.  In particular, there is no definition for what a
Replaces header in a REFER request means -- see RFC 3891.

> Is there any *UE* which sends *REFER* message with separate Replaces
> header?

I hope not.

Dale
Permalink | Reply | 0 comments |
headers
Sandro | 11 Jan 2012 14:11
Picon
Favicon

Authorization of incoming call

Hello all.

I have a theoretical question about call admitting and security.

Let's say we have two clients A&B (phones or softphones) and a
proxy/registrar.
Clients register themselves on the registrar with authentication (http
digest).
This is, i think, the most normal scenario.

Proxy authenticates incoming (from the clients) calls, this means invite
messages, with the same registrar credentials, and this gives it a certain
degree of security.

What happens for clients?
I mean, how can a client "authorize/authenticate" a call coming from the
proxy and become sure it's is *really* coming from its proxy?

Let's say for example that a "C" malicious client/proxy is sending INVITEs
to A.
How can A recognize that these INVITEs are not related to the REGISTER
"session" to the proxy?

I think this can be done checking/filtering on IP addresses.
But there are no other ways? I mean something textual like Dialog-ID or
Call-ID but negotiated during registration?
Better, can be registration used like an authorization "provider", meaning
that i accept only coming from the proxy/registrar where i am registered?

There are best practices or documentation about that?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kevin P. Fleming | 11 Jan 2012 15:11
Favicon
Gravatar

Re: Authorization of incoming call

On 01/11/2012 07:11 AM, Sandro wrote:
> Hello all.
>
> I have a theoretical question about call admitting and security.
>
> Let's say we have two clients A&B (phones or softphones) and a
> proxy/registrar.
> Clients register themselves on the registrar with authentication (http
> digest).
> This is, i think, the most normal scenario.
>
> Proxy authenticates incoming (from the clients) calls, this means invite
> messages, with the same registrar credentials, and this gives it a certain
> degree of security.
>
> What happens for clients?
> I mean, how can a client "authorize/authenticate" a call coming from the
> proxy and become sure it's is *really* coming from its proxy?
>
> Let's say for example that a "C" malicious client/proxy is sending INVITEs
> to A.
> How can A recognize that these INVITEs are not related to the REGISTER
> "session" to the proxy?

There is no perfect method to do this, but one very common method is for 
the UA that REGISTERs to include a randomly-generated token in the 
Contact URI that it supplies to the registrar; incoming INVITEs 
generated by UAs that obtained the Contact URI from that registrar will 
then include that token, and the receiving UA can 'trust' that the 
INVITE was generated by a UA that was authorized by the registrar to do so.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Vineet Menon | 12 Jan 2012 09:56
Picon
Gravatar

Re: Authorization of incoming call

Hi,

Again, you can force route all calls thru the proxy so that calls
will always be routed thru the proxy. So that, a session hijacking can be
avoided.

In addition to this, I wanted to clarify whether the use of proxy avoid
another user from calling your UA without registering to proxy ? eg. using
IP dialing...
How can this be avoided? I am peculiarly concerned because this is like
some malicious user is using your infrastructure for his own purpose. I
believe SIP in its core cannot do this!!

Regards,

Vineet Menon

On 11 January 2012 19:41, Kevin P. Fleming <kpfleming <at> digium.com> wrote:

> On 01/11/2012 07:11 AM, Sandro wrote:
> > Hello all.
> >
> > I have a theoretical question about call admitting and security.
> >
> > Let's say we have two clients A&B (phones or softphones) and a
> > proxy/registrar.
> > Clients register themselves on the registrar with authentication (http
> > digest).
> > This is, i think, the most normal scenario.
> >
(Continue reading)

Permalink | Reply | 2 comments |
headers
RAVI KUMAR | 12 Jan 2012 11:00
Picon

regrading register authorization filed (nc parameter)

Hi All,

Need your suggestion on this .
I have doubt on authorization field present in sip request
message

Please refer below link.

http://www.ietf.org/rfc/rfc2617.txt

The Authorization Request Header

   The client is expected to retry the request, passing an Authorization
   header line, which is defined according to the framework above,
   utilized as follows.

       credentials      = "Digest" digest-response
       digest-response  = 1#( username | realm | nonce | digest-uri
                       | response | [ algorithm ] | [cnonce] |
                       [opaque] | [message-qop] |
                           [nonce-count]  | [auth-param] )

       username         = "username" "=" username-value
       username-value   = quoted-string
       digest-uri       = "uri" "=" digest-uri-value
       digest-uri-value = request-uri   ; As specified by HTTP/1.1
       message-qop      = "qop" "=" qop-value
       cnonce           = "cnonce" "=" cnonce-value
       cnonce-value     = nonce-value
       nonce-count      = "nc" "=" nc-value
(Continue reading)

Permalink | Reply | 1 comment |

Gmane