Hey all,
I think there is something in the request which is wrong. I have just tried forwarding to fwd in the same way, and have tried dialling the service numbers (e.g. the time number, 612). fwd replies "too many hops" when using the pdt module, but is absolutely fine when I dial 612@fwd.pulver.com
Again, compare the messages in the syslog:
Aug 11 10:36:51 sip /sbin/ser[25289]: ACC: transaction answered: method=INVITE, i-uri=sip:83930612@sip.dev.inmarsat.com, o-uri=sip:612@fwd.pulver.com
And
Aug 11 10:35:59 sip /sbin/ser[25288]: ACC: transaction answered: method=INVITE, i-uri=sip:612@fwd.pulver.com, o-uri=sip:612@fwd.pulver.com, call_id=24369428-0E66-4DA4-AC30-CE0175B0BACE@161.30.94.150, from=Dave Bath sip:admin@sip.dev.inmarsat.com;tag=1302198395, code=200
I don't think that both the first company (I believe running cisco call manager) and fwd (which I believe runs ser as a front end?) incorrectly handle the sip message.. and anyway, it shouldn't be the next-hop proxy's job to ask for it again really... ser should send the correct invite the first time...
Is there something to do with the record route? Expecting a reply from 83930612@sip.dev.inmarsat.com instead of 612@fwd.pulver.com?
I don't think this can be it.. but I don't understand why the invite message doesn't appear to be successfully sent..
The ngrep's are attached to see the invite as sent by the UA and Ser to fwd...
-----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] Sent: 11 August 2004 09:25 To: Dave Bath Cc: serusers@lists.iptel.org Subject: Re: [Serusers] PDT module
Hello, as far as I know, pdt changes only the R-URI, so there is nothing to worry about. Anyhow, since the request leaves your system, the next proxy should report with a final response any problem it encounters (if it is a malformed request it should be 400 Bad request, or it should be at least time-out, not found a.s.o.) -- but I see only the provisional 100 Trying reply.
You can set another SER proxy in the way, just to see if the requests passes through -- use t_relay_to_udp(...) to send the request to the intermediary proxy and watch if the request is relayed further from there.
Daniel
On 8/10/2004 9:22 PM, Dave Bath wrote:
Hey Daniel,
Unfortunately, i do not maintain the system at 80.234.135.99. However,
i am not sure there is anything wrong with their system anyway.... as you see, i have attempted to dial from my UA once dialling a full address (in this case 3018 - at - sip.prodec.tv) which was responded to correctly, and once by dialling 839503018 where 83950 should be translated as sip.prodec.tv using the PDT module. Hence, ser should finally send the invite to 3018 - at - sip.prodec.tv in the same was as if i dialled the full address manually, no? There should be no difference, once that invite request, has left ser (161.30.94.136) in how the remote system handles it.
As you can see from the syslog:
ACC: transaction answered: method=INVITE, i-uri=sip:839503018 at
sip.dev.inmarsat.com, o-uri=sip:3018 at sip.prodec.tv mailto:o-uri=sip:3018@sip.prodec.tv
ACC: transaction answered: method=INVITE, i-uri=sip:3018 at
sip.prodec.tv, o-uri=sip:3018 at sip.prodec.tv mailto:o-uri=sip:3018@sip.prodec.tv , call_id=9C912086-C197-484D-8AD2-E261F1A3234A@161.30.94.150, from=Dave Bath <sip:admin at sip.dev.inmarsat.com>;tag=2122510239, code=487
for some reason using the pdt module appears to issue a malformed
invite request... unless soemthing in ser.cfg is not configured correctly.
Is my logic totally off? I appreciate your words of wisdom very much...
Dave
From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] Sent: Tue 10/08/2004 18:03 To: Dave Bath Cc: serusers@lists.iptel.org Subject: Re: [Serusers] PDT module
Hello, I see that the request was forwarded from 161.30.94.136:5060 to 80.234.135.99:5060 and you get back a 100 trying. PDT does its job on 161.30.94.136, as far as I assume, so there should be a problem on the other site 80.234.135.99, could you check that system too?
Daniel
On 8/10/2004 12:06 PM, Dave Bath wrote:
Hey Daniel and all,
Many thanks for looking into this. The first ngrep is dialling the full address, the second is using the pdt module.
------------------------- BEGIN dialling full external SIP address
U 161.30.94.150:5060 -> 161.30.94.136:5060
INVITE sip:3018@sip.prodec.tv SIP/2.0..Via: SIP/2.0/UDP 161.30.94.150:5060;rport;branch=z9hG4bKBAF99F2231994F0D9A5
3836019EAC108..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=399847332..To: sip:3018@sip.prodec.tv..Conta
ct: sip:admin@161.30.94.150:5060..Call-ID: FC2BDDD4-9E47-4C5A-9034-4977FC86290D@161.30.94.150..CSeq: 35761 INVIT
E..Max-Forwards: 70..Content-Type: application/sdp..User-Agent: X-Lite release 1103m..Content-Length: 298....v=0..
o=admin 434214617 434214657 IN IP4 161.30.94.150..s=X-Lite..c=IN IP4 161.30.94.150..t=0 0..m=audio 8000 RTP/AVP 0
8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=rtpmap:98 iLBC/8000..a=rtpmap:97
speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..
#
U 161.30.94.136:5060 -> 161.30.94.150:5060
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 161.30.94.150:5060;rport=5060;branch=z9hG4bKB
AF99F2231994F0D9A53836019EAC108..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=399847332..To: <sip:3018@sip
.prodec.tv>..Call-ID: FC2BDDD4-9E47-4C5A-9034-4977FC86290D@161.30.94.150..CSeq: 35761 INVITE..Server: Sip EXpress
router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 161.30.94.136:5060 "Noisy feedback tells: pid=13743
req_src_ip=161.30.94.150 req_src_port=5060 in_uri=sip:3018@sip.prodec.tv out_uri=sip:3018@sip.prodec.tv via_cnt==
1"....
#
U 161.30.94.136:5060 -> 80.234.135.99:5060
INVITE sip:3018@sip.prodec.tv SIP/2.0..Record-Route: sip:3018@161.30.94.136;ftag=399847332;lr=on..Via: SIP/2.0/U
DP 161.30.94.136;branch=z9hG4bK51f6.ae27ae87.0..Via: SIP/2.0/UDP 161.30.94.150:5060;rport=5060;branch=z9hG4bKBAF99
F2231994F0D9A53836019EAC108..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=399847332..To: <sip:3018@sip.pro
dec.tv>..Contact: sip:admin@161.30.94.150:5060..Call-ID: FC2BDDD4-9E47-4C5A-9034-4977FC86290D@161.30.94.150..CSe
q: 35761 INVITE..Max-Forwards: 69..Content-Type: application/sdp..User-Agent: X-Lite release 1103m..Content-Length
: 298....v=0..o=admin 434214617 434214657 IN IP4 161.30.94.150..s=X-Lite..c=IN IP4 161.30.94.150..t=0 0..m=audio 8
000 RTP/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=rtpmap:98 iLBC/800
0..a=rtpmap:97 speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..
#
U 161.30.94.136:5060 -> 80.234.135.99:5060
INVITE sip:3018@sip.prodec.tv SIP/2.0..Record-Route: sip:3018@161.30.94.136;ftag=399847332;lr=on..Via: SIP/2.0/U
DP 161.30.94.136;branch=z9hG4bK51f6.ae27ae87.0..Via: SIP/2.0/UDP 161.30.94.150:5060;rport=5060;branch=z9hG4bKBAF99
F2231994F0D9A53836019EAC108..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=399847332..To: <sip:3018@sip.pro
dec.tv>..Contact: sip:admin@161.30.94.150:5060..Call-ID: FC2BDDD4-9E47-4C5A-9034-4977FC86290D@161.30.94.150..CSe
q: 35761 INVITE..Max-Forwards: 69..Content-Type: application/sdp..User-Agent: X-Lite release 1103m..Content-Length
: 298....v=0..o=admin 434214617 434214657 IN IP4 161.30.94.150..s=X-Lite..c=IN IP4 161.30.94.150..t=0 0..m=audio 8
000 RTP/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=rtpmap:98 iLBC/800
0..a=rtpmap:97 speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..
#
U 80.234.135.99:5060 -> 161.30.94.136:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.30.94.136;branch=z9hG4bK51f6.ae27ae87.0..Via: SIP/2.0/UDP 161.30.94.150:5
060;rport=5060;branch=z9hG4bKBAF99F2231994F0D9A53836019EAC108..From: "Dave Bath" sip:admin@sip.dev.inmarsat.com;
tag=399847332..To: sip:3018@sip.prodec.tv..Call-ID: FC2BDDD4-9E47-4C5A-9034-4977FC86290D@161.30.94.150..CSeq: 35
761 INVITE..Content-Length: 0....
#
U 80.234.135.99:5060 -> 161.30.94.136:5060
SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.30.94.136;branch=z9hG4bK51f6.ae27ae87.0..Via: SIP/2.0/UDP 161.30.94.150:
5060;rport=5060;branch=z9hG4bKBAF99F2231994F0D9A53836019EAC108..Record
-Route:
<sip:sip.prodec.tv:5060;maddr=80.234
.135.99>..Record-Route: sip:3018@161.30.94.136;ftag=399847332;lr=on..From: "Dave Bath" <sip:admin@sip.dev.inmars
at.com>;tag=399847332..To: sip:3018@sip.prodec.tv;tag=q5elumfa3r..Call-ID: FC2BDDD4-9E47-4C5A-9034-4977FC86290D@
161.30.94.150..CSeq: 35761 INVITE..Contact: sip:3018@sip.prodec.tv;gruu=do1iiw55..Allow: INVITE, ACK, CANCEL, BY
E, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO..Content-Length: 0....
-------------------- END dialling full sip address ----------------
-------------------- BEGIN dialling pdt code ----------------------
#
U 161.30.94.150:5060 -> 161.30.94.136:5060
INVITE sip:839503018@sip.dev.inmarsat.com SIP/2.0..Via: SIP/2.0/UDP 161.30.94.150:5060;rport;branch=z9hG4bK4702083
ECD1D437DA04923E23027A6A5..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=570031081..To:
<sip:839503018@sip.
dev.inmarsat.com>..Contact: sip:admin@161.30.94.150:5060..Call-ID: EE63DA9A-C436-4598-B636-F3C8368E711E@161.30.9
4.150..CSeq: 64028 INVITE..Max-Forwards: 70..Content-Type: application/sdp..User-Agent: X-Lite release 1103m..Cont
ent-Length: 298....v=0..o=admin 434296285 434296325 IN IP4 161.30.94.150..s=X-Lite..c=IN IP4 161.30.94.150..t=0 0.
.m=audio 8000 RTP/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=rtpmap:9
8 iLBC/8000..a=rtpmap:97 speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..
#
U 161.30.94.136:5060 -> 161.30.94.150:5060
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 161.30.94.150:5060;rport=5060;branch=z9hG4bK4
702083ECD1D437DA04923E23027A6A5..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=570031081..To: <sip:83950301
8@sip.dev.inmarsat.com>..Call-ID: EE63DA9A-C436-4598-B636-F3C8368E711E@161.30.94.150..CSeq: 64028 INVITE..Server:
Sip EXpress router (0.8.14 (i386/linux))..Content-Length: 0..Warning: 392 161.30.94.136:5060 "Noisy feedback tells
: pid=13743 req_src_ip=161.30.94.150 req_src_port=5060 in_uri=sip:839503018@sip.dev.inmarsat.com out_uri=sip:3018
@sip.prodec.tv. via_cnt==1"....
#
U 161.30.94.136:5060 -> 80.234.135.99:5060
INVITE sip:3018@sip.prodec.tv. SIP/2.0..Record-Route: sip:839503018@161.30.94.136;ftag=570031081;lr=on..Via: SIP
/2.0/UDP 161.30.94.136;branch=z9hG4bK705d.1d3e9f23.0..Via: SIP/2.0/UDP 161.30.94.150:5060;rport=5060;branch=z9hG4b
K4702083ECD1D437DA04923E23027A6A5..From: Dave Bath sip:admin@sip.dev.inmarsat.com;tag=570031081..To: <sip:839503
018@sip.dev.inmarsat.com>..Contact: sip:admin@161.30.94.150:5060..Call-ID: EE63DA9A-C436-4598-B636-F3C8368E711E@
161.30.94.150..CSeq: 64028 INVITE..Max-Forwards: 69..Content-Type: application/sdp..User-Agent: X-Lite release 110
3m..Content-Length: 298....v=0..o=admin 434296285 434296325 IN IP4 161.30.94.150..s=X-Lite..c=IN IP4 161.30.94.150
..t=0 0..m=audio 8000 RTP/AVP 0 8 3 98 97 101..a=rtpmap:0 pcmu/8000..a=rtpmap:8 pcma/8000..a=rtpmap:3 gsm/8000..a=
rtpmap:98 iLBC/8000..a=rtpmap:97 speex/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-15..
#
U 80.234.135.99:5060 -> 161.30.94.136:5060
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.30.94.136;branch=z9hG4bK705d.1d3e9f23.0..Via: SIP/2.0/UDP 161.30.94.150:5
060;rport=5060;branch=z9hG4bK4702083ECD1D437DA04923E23027A6A5..From: "Dave Bath" sip:admin@sip.dev.inmarsat.com;
tag=570031081..To: sip:839503018@sip.dev.inmarsat.com..Call-ID: EE63DA9A-C436-4598-B636-F3C8368E711E@161.30.94.1
50..CSeq: 64028 INVITE..Content-Length: 0....
#
------- END dialling with pdt module ---------------------------
In the second case, there is nothing futher transmitted until a request timed out is received.
Many thanks for looking into this...
Dave
-----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] Sent: 10 August 2004 10:10 To: Dave Bath Cc: serusers@lists.iptel.org Subject: Re: [Serusers] PDT module
we need network traffic dumps (ngrep, ethereal) to see what happens
there.
Daniel
On 8/9/2004 4:23 PM, Dave Bath wrote:
I have been trying to use the pdt module, and the idea seems
excellent. I have the database up and running, and can enter codes. Things seem to be translated correctly, but the INVITE request is not complete, and the call always fails. Compare the following from the log file:
ACC: transaction answered: method=INVITE,
i-uri=sip:839503018@sip.dev.inmarsat.com, o-uri=sip:3018@sip.prodec.tv
ACC: transaction answered: method=INVITE,
i-uri=sip:3018@sip.prodec.tv, o-uri=sip:3018@sip.prodec.tv, call_id=9C912086-C197-484D-8AD2-E261F1A3234A@161.30.94.150, from=Dave Bath sip:admin@sip.dev.inmarsat.com;tag=2122510239, code=487
The first is dialing using the pdt module, with my code
8+395+0+<number> the second is directly dialing the full external domain address. The first fails, and I eventually get a timeout, the second connects no problem.
Excerpts from the ser.cfg are:
# loose-route processing
if (loose_route()) {
t_relay();
break;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
# label all transaction for accounting
setflag(1);
# Make sure we check the prefix tables
prefix2domain();
before the if (uri==myself) statement.
I have been bashing my head around and around for so long now, do you
have any ideas?!
Many many thanks in advance,
Dave
/-------------------------------------/
/Dave Bath/
/Inmarsat LTD/
/Global Satellite Communications/
/www.inmarsat.com http://www.inmarsat.com/ /
/Regional BGAN Engineer/
/07736 232085/
NOTE: The information contained in this email is intended for the
named recipients only, it may be privileged and confidential. If you
are not the intended recipient, you must not copy distribute or take
any action in reliance upon it. No warranties or assurances are made
in relation to the safety and content of this email and any
attachments. No liability is accepted for any consequences arising
from it
---
Serusers mailing list
serusers@lists.iptel.org
-
Dave Bath