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.
-Route:
<sip:839503018@sip.
there.
---
-
Dave Bath