headers
Brandon W. Yuille | 1 Apr 2011 04:25
Favicon

Re: dhcp lease renew on ring

Hi Josh,

What leads you to believe renewing a DHCP lease will drop your call?

Think about this: have you ever had an HTTP download break because your 
computer needed to renew it's DHCP lease? I've never experienced such a 
thing.

I'm not an expert by any means with DHCP, but if your computer sends a 
renew, why would the DHCP server drop or change that computers IP 
address? If you want expert advice with DHCP, I'd think you'd be better 
off asking this in another mailing list.

My best answer for you would be: DHCP would have been replaced by now if 
renewing a leased address caused the behavior you're describing. Now if 
there is an IP conflict on the network (some other computer has the 
leased IP statically assigned), then yes you most defiantly would have 
issues.

I hope I was able to help,
Brandon

On 03/31/2011 05:42 PM, Josh Roberts wrote:
> Mayank and friends,
>
> I'm trying to authenticate a statement by a voip/sip system integrator that
> dhcp has stability and reliability issues because when the phone rings
> (every time, according to this company) it has to check its lease for
> renewal and potentially renew the lease before the call can connect.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brandon W. Yuille | 1 Apr 2011 05:13
Favicon

Re: dhcp lease renew on ring

Hi Josh,

One last followup: I was curious to see exactly what happens when 
dhclient renews my IP address, so I captured it with wireshark and found 
that in the DHCP request, dhclient specifies the IP address it is 
requesting to be renewed (the same IP that was originally leased). The 
DHCP server finds no problem with renewing that leased IP as the MAC 
address matches the one that currently owns that lease. At the same time 
I renewed my lease I was downloading a Debian ISO. The download was 
maintained and did not break. The reason for this is the device 
transmitting the ISO packets to my computer (my Cisco router) is not 
updating it's ARP table or dropping my computer's MAC from it's table 
just because I renewed my lease on the DHCP server. Heck, it's not even 
sending out a new ARP request for my leased IP as it is oblivious to the 
fact that I renewed my lease on the DHCP server.

Anyway, this should be a definitive answer that renewing a DHCP lease 
will not prevent SIP from working like normal as proved by my testing. 
You can also test this for yourself or perform this test for your 
integrator to verify. The easiest scenario would be to install a 
softphone on your computer and call it when performing this test.

Good luck,
Brandon

On 03/31/2011 10:25 PM, Brandon W. Yuille wrote:
> Hi Josh,
>
> What leads you to believe renewing a DHCP lease will drop your call?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 1 Apr 2011 11:15
Favicon

Re: dhcp lease renew on ring

________________________________________
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Josh Roberts [josh <at> cenintage.com]

I'm trying to authenticate a statement by a voip/sip system integrator that
dhcp has stability and reliability issues because when the phone rings
(every time, according to this company) it has to check its lease for
renewal and potentially renew the lease before the call can connect.
_______________________________________________

In the very strictest sense, a device must check whether its DHCP lease has expired before
sending or listening for a packet using that IP address.  But of course, this "checking" is done
negatively -- the stack knows what address to use, and the higher-layer DHCP daemon removes
the address from the stack at those rare times when the daemon cannot renew the lease.

DHCP does *not* have stability and reliability issues in an environment that implements DHCP
well -- that has coordinated, redundant DHCP servers, which almost every IP network does.
DHCP is used in this manner by many, many enterprises, many of which have hundreds or thousands
of IP phones.

There may be certain specialized environments where using DHCP for VoIP phones is not a good idea,
but you need to have someone explain exactly why.

Dale
Permalink | Reply | 2 comments |
headers
Nikos Leontsinis | 1 Apr 2011 11:29
Picon

sip: public versus private interconnection

I wonder if there any studies comparing the difference in performance
(quality metrics) of public internet versus private on a sip
interconnection.
So far based on my personal experience there is no longer a reason to
route your traffic over a private interconnection since the public
internet is pretty stable nowdays.I personally believe that quality
and reliability concerns do not largely limit VoIP usage to either
personal calls on cross-domain services  to single-domain services
such as trunking, where a core ISP carries long-distance voice as VoIP
only within its backbone,  with a uni-
ed voice/data infrastructure. I want to investigate whether there are
any factors that prevent cross-domain VoIP deployments from
achieving the quality and reliability of existing land-line
telephony (PSTN). My results indicate that VoIP usability is no longer hindered
 by BGP's slow convergence as network congestion.
 All I can think of is security nothing else.

Any ideas/experiences on that?

/nikos
Permalink | Reply | 0 comments |
headers
Kutay OZDOGRU | 1 Apr 2011 11:33
Picon

Re: Digest-URI questions


Hi all,

Let me explain, authorization.

Lets consider these informations are provided:

username="alice <at> ericsson.com"
realm="ericsson.com"
uri="sip:ericsson.com"
password:"alice"

REGISTER sip:ericsson.com SIP/2.0
Max-Forwards: 20
CSeq: 1 REGISTER
Expires: 3600
Content-Length: 0
Contact: "Alice" <sip:alice <at> 127.0.0.1:5060>;+sip.instance=e7def040-f226-4927-bd52-a37f0fdf0067
Authorization: Digest username="alice <at> ericsson.com",realm="ericsson.com",nonce="",response="",uri="sip:ericsson.com"
User-Agent: Fokus MONSTER Version: 0.9.13
From: "Alice" <sip:alice <at> ericsson.com>;tag=1000
To: "Alice" <sip:alice <at> ericsson.com>
Call-ID: c7fd832a2175d36d8bac9c8f4bfced2d <at> 127.0.0.1
Via: SIP/2.0/UDP 127.0.0.1:5060;branch=z9hG4bK3b39625cc9b75f78d0789f5a93554dfb3536

]]]
[SDS] [INFO ] 
<-- Sent message on UDP [Local: 0.0.0.0:5081 | Remote: 127.0.0.1:5060] [[[
SIP/2.0 401 Unauthorized - Respond to challenge
CSeq: 1 REGISTER
(Continue reading)

Permalink | Reply | 4 comments |
headers
Siga | 1 Apr 2011 14:15

Re: Up-sampling received RTP payload

Hi,
when I try to feed the RTP Payload with passing through the decoder (as
mentioned by Brandon), the output is only noise. On the other hand after
passing it through the decoder I could at least hear some audio but with
noise. Can anybody give some valuable suggestions on this.

Regards

On Tue, Mar 29, 2011 at 9:00 PM, Brandon W. Yuille <bwy <at> bwysystems.com>wrote:

> Hi Siga,
>
> Isn't G.711 decoded already signed 16bits per sample  <at>  8000Hz PCM (I
> seem to remember that's what the ITU implementation outputs - signed
> short array)? I don't believe you need to do any resampling if your
> playback device is setup to use 16bit single channel 8000Hz PCM audio.
>
> Brandon
>
> On 03/29/2011 10:46 AM, Siga wrote:
> > Hi,
> > I need some assistance from the SIP professionals regarding the decoder
> > part, i am using A-Law for encoding and decoding. My encoder for  RTP
> > packets using G.711 A-law encoder works pretty much OK, but I have got
> some
> > flaws with the decoding part. Especially with the upsampling conversion
> from
> > 8 bits to 16 bits, what should be the size of the buffer for storing the
> > decoded RTP payload. I can hear some audio but with poor quality.
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Krebs | 1 Apr 2011 19:45
Picon

Re: Digest-URI questions

Hi Kutay,

Many thanks for your detailed response. However I have no problem
understanding the "common" case of digest authentication (or at least, I
hope so :-) ). To clarify my question, let's consider that the URI in your
example includes optional values, e. g.

sip:user:password <at> ericsson.com
;transport=udp;user=ip;method=INVITE;ttl=123&header=some%20header

What value should be used in the calculation of str2 in the <sip uri> part,
the whole URI as string with all optional values in the exact order they are
given above or just the mandatory parts (which would be "
sip:user <at> ericsson.com" or the one in your example without the user)?

Best regards,

Peter

2011/4/1 Kutay OZDOGRU <kutayo <at> netas.com.tr>

>
> Hi all,
>
> Let me explain, authorization.
>
> Lets consider these informations are provided:
>
> username="alice <at> ericsson.com"
> realm="ericsson.com"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brandon W. Yuille | 1 Apr 2011 21:28
Favicon

Re: Up-sampling received RTP payload

Hi Siga, the best way to test your audio code is to use the same code in 
a simple program. Write a program that reads 8000Hz 16bit single channel 
PCM from a file which then compresses it and then decompress it to an 
output file. Then playback your new output file, if it's corrupted you 
have a problem in your code. However, if it's not corrupted, then take a 
look at how your RTP code is feeding the payload into the decoder. 
Another step would be to verify that the audio being sent to you is what 
you're expecting. Wireshark has built in support to play G.711 RTP 
streams, so give that a try. If Wireshark plays back noise then you know 
it's not your problem.

Brandon

On 04/01/2011 08:15 AM, Siga wrote:
> Hi,
> when I try to feed the RTP Payload with passing through the decoder 
> (as mentioned by Brandon), the output is only noise. On the other hand 
> after passing it through the decoder I could at least hear some audio 
> but with noise. Can anybody give some valuable suggestions on this.
>
> Regards
>
> On Tue, Mar 29, 2011 at 9:00 PM, Brandon W. Yuille <bwy <at> bwysystems.com 
> <mailto:bwy <at> bwysystems.com>> wrote:
>
>     Hi Siga,
>
>     Isn't G.711 decoded already signed 16bits per sample  <at>  8000Hz PCM (I
>     seem to remember that's what the ITU implementation outputs - signed
>     short array)? I don't believe you need to do any resampling if your
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brez Borland | 2 Apr 2011 16:05
Picon

RTP header followed by the RTP header extension

 Hello folks,

Apologies if this should not go onto this list, please suggest where else
should I look for advice in this case.

Below is the snip from the rfc3550, which is a bit confusing. Fields X and
CC specify that, if set, they MUST follow the RTP header. My question is, if
both X and CC are present which of these must take precedence in following
RTP header.

----------------------------------------------------------

5.1 RTP Fixed Header Fields:

   ......

      extension (X): 1 bit

            * If the extension bit is set, the fixed header MUST be followed
by exactly one header extension*, with a format defined in Section 5.3.1.

       CSRC count (CC): 4 bits

             The CSRC count contains *the number of CSRC identifiers that
follow the fixed header*.

----------------------------------------------------------

Input is greatly appreciated. Let me know if clarification of the question
is needed.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Krebs | 2 Apr 2011 20:07
Picon

Re: RTP header followed by the RTP header extension

Hello,

>From RFC 3550, sec. 5.3.1:

"If the X bit in the RTP header is one, a variable-length header extension
MUST be appended to the RTP header, following the CSRC list if present."

So, CSRC list first, then extension header :-).

Best regards,

Peter

On Sat, Apr 2, 2011 at 4:05 PM, Brez Borland <brezden <at> gmail.com> wrote:

>  Hello folks,
>
> Apologies if this should not go onto this list, please suggest where else
> should I look for advice in this case.
>
> Below is the snip from the rfc3550, which is a bit confusing. Fields X and
> CC specify that, if set, they MUST follow the RTP header. My question is,
> if
> both X and CC are present which of these must take precedence in following
> RTP header.
>
> ----------------------------------------------------------
>
> 5.1 RTP Fixed Header Fields:
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane