Bronko

It seems to be solved in upcoming 5.2.7 release. Stay tuned...

I'm currently testing behaviour under next release 5.2.7. Will be back...

Thats the problem exactly, it doesn't stick to the register IP address! The invite IP address is a different one. Thanks for the private board message; will be back here asap.

Yes. I did it with a new FreeBSD installation.

Back again for the 403 (Forbidden) problem: It seems the main problem is given by the fact that the REGISTER is send to server 217.0.18.68 and the call INVITE to server 217.0.20.230. These both IPs are only examples for a lot of SBCs for the domain "tel.t-online.de". The registry string is not the same as the one from the invite, and there for you get forbidden message. It helps to set the "Proxy Address" to "sip:217.0.18.68" for the trunk, but isn't really nice. Any (hidden) configuration option for that, like "insecure=port,invite" for asterisk?

Ok, but not visible here. I have to capture it...

How long does it take (nothing after 20 min for a factory reseted phone) and what is the technical background of these "scanning the network" (kind of packets)?

Hello, we have two wiki articles: http://wiki.snom.com/Features/Auto_Provisioning/phone http://wiki.snom.com/Features/Auto_Provisioning/Bootup Which is the right one? BR, Jan

Solved! Many thanks...

Solved! Many thanks...

Hi, email is on the way... yes, from second hand.

That means, there is a difference between reset and factory reset via tftp?

Did not really know what you mean, but software updates are no problem and make a RESETs works successfully. After the RESET the phone config is shown greyed for the "Setting URL" (see above). Solution until the next RESET: Download xml config, modify R->RW for the URL, load config and have fun... ;-)

Hello, it seems I have bought 4 branded phones (370.870), means the Setting URL under the Update section is hard coded (shown greyed). Any way for an unbranding?

Ok, the same on a snom370... May be I have bought QSC (german voip provider) branded phones? Any option for unbranding?

Hello, under ->Advanced ->Update the "Setting URL" is shown greyed, whatever is selected in "Update Policy". Sip Notify (also from the Test Tool in python) or DHCP option 66 doesn't overwrite it. Resetting the phone doesn't help. The relevant log entries: Aug 10 17:20:39 [NOTICE] PHN: Setting server prio 1, type redirection, url: >https://xsp1.bmcag.com/dms/snom/snom870.xml< Aug 10 17:20:39 [INFO ] PHN: ProvisioningReplacements: URL >https://xsp1.bmcag.com/dms/snom/snom870.xml< Any hints? BR, Jan

set it to 20 and it helps, not perfectly but essentially... http://kiwi.pbxnsip.com/index.php/Troubleshooting_SIP_Trunk_Problems

Same behaviour, often a call forbidden (403); manual trunkreg helps... Any idea?

no comment?

OK, this is my trunk setting for several years, but in the last few months I have a lot of "403" before I can make a call: # Trunk 4 in domain snomone.lan.home Name: 03012345678 Type: register RegPass: PASSWORD Direction: Disabled: false Global: false Display: 03012345678 RegAccount: 03012345678 RegRegistrar: tel.t-online.de WrtcDestName: WrtcDestNumber: RegKeep: 30 RegUser: USERNAME@t-online.de Icid: Require: OutboundProxy: tel.t-online.de Ani: 03012345678@tel.t-online.de DialExtension: 72 Trusted: false AcceptRedirect: false RfcRtp: false BehindNat: false RtcpXr: false Analog: false RtpBegin: RtpEnd: Prack: true SendEmail: UseUuid: false Ring180: false Failover: never HeaderRequestUri: {request-uri} HeaderFrom: {trunk-ani} HeaderTo: {request-uri} HeaderPai: HeaderPpi: HeaderRpi: HeaderPrivacy: 12345678 HeaderRpiCharging: icid-value={icid-value};icid-generated-at={ip-address};orig-ioi={domain} BlockCidPrefix: Glob: RequestTimeout: Codecs: CodecLock: true Pcap: false DtmfMode: Expires: 3600 Fraction: 128 Minimum: 10 FromUser: FromSource: ppi Tel: true TranscodeDtmf: false AssociatedAddresses: InterOffice: false DialPlan: UseEpid: false CidUpdate: Ignore18xSDP: false UserHdr: Diversion: CoBusy: 500 Line Unavailable CoDest: Colines: DialogPermission:

Hi, I'm very interested in! Any news?

Ok, but what was the problem in call counting?

Thanks a lot! Works as it should! Can you describe the issue a little bit deeper? Any documentation for that?

Ok, thanks a lot, but no changes! Some precisions: (internal: extension to extension, external: over trunk) 1st call internal - 2nd external call failed 1st call external - 2nd external call failed 1st call external - 2nd internal call works! 1st call internal - 2nd internal call works! Means, only if the 2nd call is an internal, it works fine and the try to establish a 3rd call extend the log as expected by: System has already 2 calls, rejecting additional 1 calls because of maximum 2 Port xx: Reject call because of too many calls in domain

any rumours?