headers
Igor Goncharovsky | 1 Nov 2008 09:22
Picon
Gravatar

Sending BYE right after REFER

Hi, All!

I am faced with error in one SIP realization and try to fix it. I am
need to know what right behavior in that situation. Client call B2BUA,
server answer and must redirect to another location. Server send REFER
and for some reason send BYE after REFER and finish dialog.

1. Can UAS send BYE right after REFER sent?
2. If that happens what reply must be sent for 401 Unauth, received in
response to REFER?

This is current message flow:

   192.168.1.120                  192.168.1.1
   |                               |
1 : |U------------INVITE----------->|
2 : |<------100 Trying/INVITE------U|
3 : |<--------200 OK/INVITE--------U|
4 : |U-------------ACK------------->|
5 : |U------------INVITE----------->|
6 : |<------100 Trying/INVITE------U|
7 : |<--------200 OK/INVITE--------U|
8 : |U-------------ACK------------->|
9 : |U--------audio/PCMA(8)-------->|
10: |<------------REFER------------U|
11: |<-------------BYE-------------U|
12: |U-----401 Unauthorized/REFER-->|
13: |U-----401 Unauthorized/BYE---->|
14: |<-------------BYE-------------U|
15: |U----------200 OK/BYE--------->|
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vikram Chhibber | 1 Nov 2008 10:27
Picon

Re: Sending BYE right after REFER

As per your call flow, it seems that there is some problem with the
Authorization header in the REFER and IMO this issue has nothing to do
with REFER and BYE race-condition. There are many implementations
which send BYE immediately after sending REFER.
You may like to see RFC 5057 on multiple dialog usage.
IMO, the best practice would be that the UAC (If it is sending
mid-dialog REFER) should wait for either REFER 2xx response or NOTIFY
before sending BYE request. This would ensure that the usage count of
the dialog is incremented and would avoid REFER/BYE race in which
case, if BYE reached first, it would terminate the dialog.

If REFER is being sent out-of-dialog, then BYE can be send immediately
after REFER.

On Sat, Nov 1, 2008 at 1:52 PM, Igor Goncharovsky
<igor.goncharovsky <at> gmail.com> wrote:
> Hi, All!
>
> I am faced with error in one SIP realization and try to fix it. I am
> need to know what right behavior in that situation. Client call B2BUA,
> server answer and must redirect to another location. Server send REFER
> and for some reason send BYE after REFER and finish dialog.
>
> 1. Can UAS send BYE right after REFER sent?
> 2. If that happens what reply must be sent for 401 Unauth, received in
> response to REFER?
>
> This is current message flow:
>
>   192.168.1.120                  192.168.1.1
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Sparks | 1 Nov 2008 19:51
Favicon

Re: Sending BYE right after REFER

There was an instance of BYE-right-after-REFER at the most recent SIPit.

This does not violate spec, and the BYE does _NOT_ terminate the dialog
(it terminates the INVITE usage and any sessions that usage may have  
negotiated - see RFC5057).

Assuming the REFER is being used to realize a transfer, what the  
element sending the
REFER followed immediately by BYE is saying is that it's not going to  
try to recover the original
call if the transfer fails. If it also doesn't care if the INVITE the  
REFER triggers succeeds or not, it
should consider asking for the norefersub extension.

RjS

On Nov 1, 2008, at 4:27 AM, Vikram Chhibber wrote:

> As per your call flow, it seems that there is some problem with the
> Authorization header in the REFER and IMO this issue has nothing to do
> with REFER and BYE race-condition. There are many implementations
> which send BYE immediately after sending REFER.
> You may like to see RFC 5057 on multiple dialog usage.
> IMO, the best practice would be that the UAC (If it is sending
> mid-dialog REFER) should wait for either REFER 2xx response or NOTIFY
> before sending BYE request. This would ensure that the usage count of
> the dialog is incremented and would avoid REFER/BYE race in which
> case, if BYE reached first, it would terminate the dialog.
>
> If REFER is being sent out-of-dialog, then BYE can be send immediately
(Continue reading)

Permalink | Reply | 0 comments |
headers
PRABHU KARTHIK | 3 Nov 2008 05:53
Favicon

Re: sdp with missing m line

Hi Paul, Vikaram, Rockson, Somesh.
Thanks on your expert opinion.
Karthik

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of
Paul Kyzivat
Sent: Friday, October 31, 2008 5:38 PM
To: karthik karthik
Cc: sip-implementors <at> lists.cs.columbia.edu
Subject: Re: [Sip-implementors] sdp with missing m line

karthik karthik wrote:
> Hello All,
> 
> Please let me know the behavior for the below cases.
> I believe 'm=' line is not mandatory according to rfc 4566
> Still It was decided to release the session in our application.
> 
> case1:
> Invite is received with SDP, and has no 'm=' line.
> In case we need to reject such an Invite,
> what is the most suitable response code?
> Could we use 415 unsupported media type.?

Note that it is legal for there to be no media.
So you could accept the call and then reinvite with the media you want 
to use. But if you want to reject, I guess 415 is as good as anything. I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Viresh.Gupta | 3 Nov 2008 13:38
Picon
Favicon

rtpmap:18 G729a/8000 ?

Hi,
        Please let me know if "rtpmap:18 G729a/8000" is a wrong format. 

I guess RFC3551 says it should work (page 19, as pasted below) and I am 
not able to find anything so specific in RFC3550. 

--------------------------------------------------------------------------------------------
4.5.6 G729
   G729 is specified in ITU-T Recommendation G.729, "Coding of speech at
   8 kbit/s using conjugate structure-algebraic code excited linear
   prediction (CS-ACELP)".  A reduced-complexity version of the G.729
   algorithm is specified in Annex A to Rec. G.729.  The speech coding
   algorithms in the main body of G.729 and in G.729 Annex A are fully
   interoperable with each other, so there is no need to further
   distinguish between them.  An implementation that signals or accepts
   use of G729 payload format may implement either G.729 or G.729A
   unless restricted by additional signaling specified elsewhere related
   specifically to the encoding rather than the payload format.  The
   G.729 and G.729 Annex A codecs were optimized to represent speech
   with high quality, where G.729 Annex A trades some speech quality for
   an approximate 50% complexity reduction [10].  See the next Section
   (4.5.7) for other data rates added in later G.729 Annexes.  For all
   data rates, the sampling frequency (and RTP timestamp clock rate) is
   8,000 Hz.
----------------------------------------------------------------------------------------------

Thanks & Regards
Viresh Gupta
Manager - International Network Planning
Enterprise Services, Bharti Airtel Limited,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Somesh S. Shanbhag | 3 Nov 2008 13:47
Favicon

Re: rtpmap:18 G729a/8000 ?

I think you need to represent in two lines

a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no

Somesh S Shanbhag
M G L Bangalore

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu on behalf of Viresh.Gupta <at> Airtel.in
Sent: Mon 11/3/2008 6:08 PM
To: sip-implementors <at> lists.cs.columbia.edu
Subject: [Sip-implementors] rtpmap:18 G729a/8000 ?

Hi,
        Please let me know if "rtpmap:18 G729a/8000" is a wrong format. 

I guess RFC3551 says it should work (page 19, as pasted below) and I am 
not able to find anything so specific in RFC3550. 

--------------------------------------------------------------------------------------------
4.5.6 G729
   G729 is specified in ITU-T Recommendation G.729, "Coding of speech at
   8 kbit/s using conjugate structure-algebraic code excited linear
   prediction (CS-ACELP)".  A reduced-complexity version of the G.729
   algorithm is specified in Annex A to Rec. G.729.  The speech coding
   algorithms in the main body of G.729 and in G.729 Annex A are fully
   interoperable with each other, so there is no need to further
   distinguish between them.  An implementation that signals or accepts
   use of G729 payload format may implement either G.729 or G.729A
(Continue reading)

Permalink | Reply | 0 comments |
headers
Attila Sipos | 3 Nov 2008 15:05

Re: rtpmap:18 G729a/8000 ?

no, annexb and annexa are different things:
annexa is a codec efficiency improvement
annexb is silence suppression

In practice, I have seen usage of "rtpmap:18 G729a/8000"
but it has no RFC-based meaning.

There is no way to indicate g729A.  You just have to use g729.
The reason for lack of g729a in RFC 3550 is that g729 and g729a
should interoperate seemlessly - as it says...

   "The speech coding
   algorithms in the main body of G.729 and in G.729 Annex A are fully
   interoperable with each other, so there is no need to further
   distinguish between them. "

(It is strange how strong the text is - I would say that the "there is
no need
 to further distinguish between them" is a matter of opinion.  Some
people will
 claim  they prefer G729 (non-annexA)  but anyway, there is no
RFC-standard way
 to indicate this in SDP as far as I know).

Regards,

Attila

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
(Continue reading)

Permalink | Reply | 501 comments |
headers
Subbu Rajendran | 3 Nov 2008 17:52
Picon

Re: SIP media change - Is the precedence for c=0.0.0.0 or a= attribute?

I was trying to prove that if offer contains c=0.0.0.0 and any one of the
a=recvonly/sendonly/sendrecv/inactive attribute then the client can safely
process this offer in the same manner as for hold. I think I confused things
with my explanation in my previous email :-)

For the example used below, the gateway GW2 supports call hold using both
RFC 3261 (c=0.0.0.0) and RFC 3264 (a=inactive) methods.

Say SIP gateway GW1 sends an offer in reinvite to another gateway GW2 with
SDP containing c=0.0.0.0 and a=recvonly. As per O/A model, GW2 can generate
answer with SDP containing valid IP & a=sendonly or inactive. Since GW2 can
neither send any RTP/RTCP as the destination media address is not known nor
receive any RTP/RTCP from 0.0.0.0, it would be more appropriate that the
answer contains a=inactive. The '0.0.0.0' is a reserved value and is seldom
used as a packet address, and is not normally valid. The valid c= address in
the answer from GW 2 serves no purpose here or does it?

Similarly, GW1 sends an offer in reinvite to GW2 with SDP containing c=
0.0.0.0 and a=sendonly. As per O/A model GW2 can generate answer with SDP
containing valid IP & a=recvonly or inactive. Since GW2 can neither receive
any RTP/RTCP from 0.0.0.0 nor send any RTP/RTCP as the destination media
address is not known, it would be appropriate that the answer contains
a=inactive. Again, the valid c= address in the answer from GW 2 serves no
purpose here or does it?

If this c=address in the answer from GW2 has no purpose then it can as well
send c=0.0.0.0. Eventually making the answer contain c=0.0.0.0 and
a=inactive which is nothing but the answer, from a GW that supports both RFC
2543 and RFC 3264, for an offer to put the call on hold.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Kyzivat | 3 Nov 2008 18:59
Picon
Favicon

Re: SIP media change - Is the precedence for c=0.0.0.0 or a= attribute?


Subbu Rajendran wrote:
> I was trying to prove that if offer contains c=0.0.0.0 <http://0.0.0.0> 
> and any one of the a=recvonly/sendonly/sendrecv/inactive attribute then 
> the client can safely process this offer in the same manner as for hold. 

I don't know what you mean when you say "the client can safely process 
this offer in the same manner as for hold". I have the following 
confusion with that simple statement:

- do you mean "client" or "server"? From context I think you mean server.

- or do you really mean "answerer"? While the server is often the 
answerer, not always.

- even if you meant both server and answerer, I don't know what you 
mean, because while the offerer can know that the intent was "hold" the 
answerer cannot ever know that.

> I think I confused things with my explanation in my previous email :-)
> 
> For the example used below, the gateway GW2 supports call hold using 
> both RFC 3261 (c=0.0.0.0 <http://0.0.0.0>) and RFC 3264 (a=inactive) 
> methods.
> 
> Say SIP gateway GW1 sends an offer in reinvite to another gateway GW2 
> with SDP containing c=0.0.0.0 <http://0.0.0.0> and a=recvonly.

I don't understand the <http://0.0.0.0> above!
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harsha. R | 4 Nov 2008 05:00
Picon

Re: rtpmap:18 G729a/8000 ?

I second Attila. Therefore if you want to use G729 Annex A encoding, do so
using G729 in a-line of sdp, and encode using
G729 annex A in bearer. G729 and "G729 Annex A" are inter-operable and there
should be no difficulties.

However you should specifically mention "annexb=no" as absence of this
parameter implies G729 Annex B
usage as mentioned in RFC4856 section 2.1.9

"        annexb: indicates that Annex B, voice activity detection, is
        used or preferred.  Permissible values are "yes" and "no"
        (without the quotes); "yes" is implied if this parameter is
        omitted.
"

2008/11/3 Attila Sipos <attila.sipos <at> vegastream.com>

> no, annexb and annexa are different things:
> annexa is a codec efficiency improvement
> annexb is silence suppression
>
> In practice, I have seen usage of "rtpmap:18 G729a/8000"
> but it has no RFC-based meaning.
>
> There is no way to indicate g729A.  You just have to use g729.
> The reason for lack of g729a in RFC 3550 is that g729 and g729a
> should interoperate seemlessly - as it says...
>
>
> Regards,
(Continue reading)

Permalink | Reply | 501 comments |

Gmane