Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Session Initiation Protocol
49 views
Skip to first unread message
Mark
Mar 27, 2013, 7:59:41 AM3/27/13
to
Hello,
Does SIP v2.0 permit to have the protocol running over non-standard ports
(not 5060)? I've checked through the specification, but wasn't able to find
an answer. It looks like a port can be negotiated and determined during a
registration phase, but I could not confirm this with RFC.
I would appreciate if anyone could help me with this. Thanks !
Mark
Does SIP v2.0 permit to have the protocol running over non-standard ports
(not 5060)? I've checked through the specification, but wasn't able to find
an answer. It looks like a port can be negotiated and determined during a
registration phase, but I could not confirm this with RFC.
I would appreciate if anyone could help me with this. Thanks !
Mark
glen herrmannsfeldt
Mar 27, 2013, 1:25:45 PM3/27/13
to
Mark <mark_cruz...@hotmail.com> wrote:
> Does SIP v2.0 permit to have the protocol running over non-standard ports
> (not 5060)? I've checked through the specification, but wasn't able to find
> an answer. It looks like a port can be negotiated and determined during a
> registration phase, but I could not confirm this with RFC.
As a general rule, both TCP and UDP should be able to run over any
> Does SIP v2.0 permit to have the protocol running over non-standard ports
> (not 5060)? I've checked through the specification, but wasn't able to find
> an answer. It looks like a port can be negotiated and determined during a
> registration phase, but I could not confirm this with RFC.
port that the server recognizes. If you can only configure on end,
then you are stuck.
Some VoIP providers will open many UDP ports to accept incoming SIP
connections, others only one. As well as I understand it, the port
that RTP runs on is configured through SIP.
If you are configuring a SIP server, you can select (almost)
any port you want.
> I would appreciate if anyone could help me with this. Thanks !
more flexible with its ports.
A TCP connection is identified by the quad: source address, source
port, destination address, destination port. If replies come back
with one of those changed, it won't be recognized. Consider what
happens when two people make telnet (or any TCP protocol) connections
from the same host to the same server.
Most often, though, UDP only requires the destination (of replies) to
match. When a UDP request is received by a server, replies are sent to
the source address and source port of the request. Most clients will
recognize the replies, even if they come from (have a source address
or source port) different from the one they sent out.
Among others, that means that multiple SIP connections from the same
host (many boxes support two) should have a different port.
-- glen
Mark
Apr 1, 2013, 4:34:31 PM4/1/13
to
"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:kiva2p$2i9$1...@speranza.aioe.org...
[skip]
> If you are configuring a SIP server, you can select (almost)
> any port you want.
>
>> I would appreciate if anyone could help me with this. Thanks !
>
> I believe both SIP and RTP run over UDP, which tends to be much
> more flexible with its ports.
>
> A TCP connection is identified by the quad: source address, source
> port, destination address, destination port. If replies come back
> with one of those changed, it won't be recognized. Consider what
> happens when two people make telnet (or any TCP protocol) connections
> from the same host to the same server.
>
Thanks for feedback!
> any port you want.
>
>> I would appreciate if anyone could help me with this. Thanks !
>
> I believe both SIP and RTP run over UDP, which tends to be much
> more flexible with its ports.
>
> A TCP connection is identified by the quad: source address, source
> port, destination address, destination port. If replies come back
> with one of those changed, it won't be recognized. Consider what
> happens when two people make telnet (or any TCP protocol) connections
> from the same host to the same server.
>
What are the mechanisms to validate the UDP payload in case of SIP? SIP
message doesn't contain size of header or the body, so how to verify that
the payload is valid? In contrast, RTP indicates the size, so given the
length value from UDP header it is possible to check RTP for validit and
integrity. Can something similar be done for SIP?
Thanks.
Mark
glen herrmannsfeldt
Apr 1, 2013, 8:44:08 PM4/1/13
to
Mark <mark_cruz...@hotmail.com> wrote:
(snip, I wrote)
> Thanks for feedback!
> What are the mechanisms to validate the UDP payload in case of SIP? SIP
> message doesn't contain size of header or the body, so how to verify that
> the payload is valid? In contrast, RTP indicates the size, so given the
> length value from UDP header it is possible to check RTP for validit and
> integrity. Can something similar be done for SIP?
I don't know either SIP or RTP in that much detail. Normally UDP runs
with a checksum. Most often, it runs over a hardware layer that supports
a CRC on the packet.
There are stories that in the early days of NFS (Sun's Network File
System) that was usually run only across a local network, that Sun would
turn off the UDP checksum. (The normal checksum can't be zero. If it is,
it is considered to be turned off.) They then relied on ethernet to
check the data. As people started using NFS over longer distances, or
across networks within an organization, and as machines got faster,
that stopped.
For some years, I had my home computers connected to the internet
through SLIP, which doesn't have a packet CRC. I never tried to run
NFS over it, though. As far as I know, all the popular link level
protocols now have a CRC. Errors inside a router are still possible.
Well, it is usual for a router to update the checksum when changing
the TTL on the packer instead of recomputing it. Maybe not always,
though.
Otherwise, if the SIP data is wrong then that packet will likely not
function, but the next one will.
-- glen
(snip, I wrote)
>> I believe both SIP and RTP run over UDP, which tends to be much
>> more flexible with its ports.
(snip)
>> more flexible with its ports.
> Thanks for feedback!
> What are the mechanisms to validate the UDP payload in case of SIP? SIP
> message doesn't contain size of header or the body, so how to verify that
> the payload is valid? In contrast, RTP indicates the size, so given the
> length value from UDP header it is possible to check RTP for validit and
> integrity. Can something similar be done for SIP?
with a checksum. Most often, it runs over a hardware layer that supports
a CRC on the packet.
There are stories that in the early days of NFS (Sun's Network File
System) that was usually run only across a local network, that Sun would
turn off the UDP checksum. (The normal checksum can't be zero. If it is,
it is considered to be turned off.) They then relied on ethernet to
check the data. As people started using NFS over longer distances, or
across networks within an organization, and as machines got faster,
that stopped.
For some years, I had my home computers connected to the internet
through SLIP, which doesn't have a packet CRC. I never tried to run
NFS over it, though. As far as I know, all the popular link level
protocols now have a CRC. Errors inside a router are still possible.
Well, it is usual for a router to update the checksum when changing
the TTL on the packer instead of recomputing it. Maybe not always,
though.
Otherwise, if the SIP data is wrong then that packet will likely not
function, but the next one will.
-- glen
Pascal Hambourg
Apr 5, 2013, 3:53:28 AM4/5/13
to
Hello,
glen herrmannsfeldt a écrit :
data payload.
> Well, it is usual for a router to update the checksum when changing
> the TTL on the packer instead of recomputing it. Maybe not always,
> though.
The UDP pseudo-header does not include the TTL, so routers do not need
to recompute the UDP checksum when forwarding a packet. They only
recompute the IP header checksum.
glen herrmannsfeldt a écrit :
>
> I don't know either SIP or RTP in that much detail. Normally UDP runs
> with a checksum. Most often, it runs over a hardware layer that supports
> a CRC on the packet.
The optional UDP checksum only covers the UDP pseudo-header, not the
> I don't know either SIP or RTP in that much detail. Normally UDP runs
> with a checksum. Most often, it runs over a hardware layer that supports
> a CRC on the packet.
data payload.
> Well, it is usual for a router to update the checksum when changing
> the TTL on the packer instead of recomputing it. Maybe not always,
> though.
to recompute the UDP checksum when forwarding a packet. They only
recompute the IP header checksum.
Jorgen Grahn
Apr 5, 2013, 4:39:18 AM4/5/13
to
On Fri, 2013-04-05, Pascal Hambourg wrote:
> Hello,
>
> glen herrmannsfeldt a �crit :
Checksum is the 16-bit one's complement of the one's complement sum
of a pseudo header of information from the IP header, the UDP
header, and the data, padded with zero octets at the end (if
necessary) to make a multiple of two octets.
How optional it is today can also be debated, I suspect. IIRC it's not
optional over IPv6. And there's also UDP Lite.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
> Hello,
>
> glen herrmannsfeldt a �crit :
>>
>> I don't know either SIP or RTP in that much detail. Normally UDP runs
>> with a checksum. Most often, it runs over a hardware layer that supports
>> a CRC on the packet.
>
> The optional UDP checksum only covers the UDP pseudo-header, not the
> data payload.
Not true -- see RFC 768:
>> I don't know either SIP or RTP in that much detail. Normally UDP runs
>> with a checksum. Most often, it runs over a hardware layer that supports
>> a CRC on the packet.
>
> The optional UDP checksum only covers the UDP pseudo-header, not the
> data payload.
Checksum is the 16-bit one's complement of the one's complement sum
of a pseudo header of information from the IP header, the UDP
header, and the data, padded with zero octets at the end (if
necessary) to make a multiple of two octets.
How optional it is today can also be debated, I suspect. IIRC it's not
optional over IPv6. And there's also UDP Lite.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Barry Margolin
Apr 5, 2013, 10:42:27 AM4/5/13
to
In article <kjlvtr$1aq6$1...@saria.nerim.net>,
--
Barry Margolin
Arlington, MA
Pascal Hambourg <boite-...@plouf.fr.eu.org> wrote:
> Hello,
>
> glen herrmannsfeldt a écrit :
> >
> > I don't know either SIP or RTP in that much detail. Normally UDP runs
> > with a checksum. Most often, it runs over a hardware layer that supports
> > a CRC on the packet.
>
> The optional UDP checksum only covers the UDP pseudo-header, not the
> data payload.
You're thinking of the IP header checksum, not the UDP checksum.
> Hello,
>
> glen herrmannsfeldt a écrit :
> >
> > I don't know either SIP or RTP in that much detail. Normally UDP runs
> > with a checksum. Most often, it runs over a hardware layer that supports
> > a CRC on the packet.
>
> The optional UDP checksum only covers the UDP pseudo-header, not the
> data payload.
--
Barry Margolin
Arlington, MA
Pascal Hambourg
Apr 6, 2013, 1:57:42 PM4/6/13
to
Barry Margolin a écrit :
carefully enough and didn't see the "and the data" part...
> Pascal Hambourg <boite-...@plouf.fr.eu.org> wrote:
>
>> The optional UDP checksum only covers the UDP pseudo-header, not the
>> data payload.
>
> You're thinking of the IP header checksum, not the UDP checksum.
Yes, my bad. I reread the RFC to check before writing my reply, but not
>
>> The optional UDP checksum only covers the UDP pseudo-header, not the
>> data payload.
>
> You're thinking of the IP header checksum, not the UDP checksum.
carefully enough and didn't see the "and the data" part...
0 new messages